This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: epoll_pwait broken?
Sorry for breaking the message threading but I'm not subscribed to the list so I only saw your post when I checked the archives.
> 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.
The "new documentation to read" - if you're talking the linux man pages, which is the most complete documentation of linux system calls that I'm aware of, I can almost guarantee that epoll_pwait will not have the "signal set size" parameter listed, just like sigtimedwait, ppoll, and others.
(see "man sigtimedwait").
Anyone who is familiar, or who needs to become familiar with the user space (glibc) interface to the kernel, will quickly get the notion that sycalls requiring a "signal set size" parameter are implemented as libc functions which do not require the parameter.
> There is internal implementation consistency, but wouldn't it be
> simpler if we just consistently exported the interface untouched?
Simpler from an implementation-in-glibc point of view, yes.
> My previous pros and cons still stand. If there isn't a good reason to
> mask the kernel interface, then I why do it?
Not all the cons do still stand; it's actually more efficient on some architectures to handle the parameter in glibc, as I've pointed out.
> Over time code builds up and incurs a maintenance penalty.
Yes, but there are other considerations too.
> Please convince me that masking the kernel interface is usefull?
Not really my job, but...
> Is there a binary compatibility aspect we haven't covered?
> What if sigset_t grows larger in the future?
Exactly. As you said yourself, if the user passes in the wrong size the kernel returns EINVAL. So what do they pass in? At the moment sizeof(sigset_t) is 128 in glibc. According to the kernel, it's 8. The glibc sigset size allows for future growth; to expose the real set size to the user would inhibit that, even if it would allow calling epoll_pwait with the 6th argument.
It's not possible to change the size of sigset_t in glibc anyway; it would break binary compatibility.
Davin.