On 8/1/05, Dave Airlie <[email protected]> wrote:
> >
> > However, there is in fact no bug here. The test program is just wrong.
> > sigwait returns zero or an error number, as POSIX specifies. Conversely,
> > sigtimedwait and sigwaitinfo either return 0 or set errno and return -1.
> > It is odd that the interfaces of related functions differ in this way,
> > but they do.
>
> The someone should fix the manpage, it explicitly says
> "The sigwait function never returns an error."
>
> Which is clearly wrong if it can return EINTR...
>
As I read SUSv3 , sigwait /can/ return error, but EINTR is not one
that it's supposed to ever return.
>From http://www.opengroup.org/onlinepubs/009695399/functions/sigwait.html :
...
ERRORS
The sigwait() function may fail if:
[EINVAL]
The set argument contains an invalid or unsupported signal number.
...
EINVAL is the only defined error for sigwait.
Also, at the start of the thread Ulrich Drepper said "The kernel
simply doesn't restart the function in case of a signal. It should do
this, though." .
I'm not quite sure you are right Ulrich. Given this little bit from
SUSv3 about SA_RESTART in the page describing sigaction (
http://www.opengroup.org/onlinepubs/009695399/functions/sigaction.html
) :
...
SA_RESTART
This flag affects the behavior of interruptible functions; that
is, those specified to fail with errno set to [EINTR]. If set, and a
function specified as interruptible is interrupted by this signal, the
function shall restart and shall not fail with [EINTR] unless
otherwise specified. If the flag is not set, interruptible functions
interrupted by this signal shall fail with errno set to [EINTR].
...
by that definition, that interruptible functions are those "specified
to fail with errno set to [EINTR]", I don't see how sigwait can be
considered an interruptible function since it
a) doesn't set errno
b) doesn't even list EINTR as a defined error return
And if sigwait is not an interruptible function, then how would it be
correct for the kernel to restart it ?
Also, the sigwait page (linked above) also says that "The sigwait()
function shall select a pending signal from set, atomically clear it
from the system's set of pending signals, and return that signal
number in the location referenced by sig." - the word that stands out
to me here is "atomically" - how can it be atomic if it is allowed to
be interrupted by signals?
What am I missing?
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
|
|