This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: epoll_pwait broken?


On 1/23/07, Davin McCall <davmac@davmac.org> wrote:
It would be inconsistent not to do the same thing for epoll_pwait.

From the users viewpoint there is no consistency, it is always a new
interface, with new documentation to read. They get little or no
benefit.

There is internal implementation consistency, but wouldn't it be
simpler if we just consistently exported the interface untouched?

My previous pros and cons still stand. If there isn't a good reason to
mask the kernel interface, then I why do it?

Yes, there's more code in glibc, but it's not such a huge deal. In terms of the binary, it comes out as a single extra "load constant" instruction.

Over time code builds up and incurs a maintenance penalty.


Please convince me that masking the kernel interface is usefull?

Is there a binary compatibility aspect we haven't covered?
What if sigset_t grows larger in the future?

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]