"A month of sundays ago Alan Cox wrote:"
> > What IS the magic combination that makes select interruptible
> > by honest-to-goodness non-blocked signals!
> man
>
> [seriously man sigaction]
Equally seriously .. all signals are unblocked in my code and always
have been. The processes receive signals vurrrrry happily. Except when
they are in a select-with-timeout loop, when they keep going round the
loop poking their head out of the select every 5s, and taking no notice
of the murderous hail of die die die die die stuff being slammed at
them.
You can see stuff such as the following early on in my code:
// handle every s¡ngle signal in one "sighandler"
for (k = 1; k < 30; k++) {
struct sigaction sa = { {sighandler}, {{0}}, SA_RESTART, NULL };
sigfillset(& sa.sa_mask);
sigaction(k, & sa, NULL);
}
But does select come out of this loop?
while (1) {
int res = select(n,rfds,wfds,efds,&timeout);
if (res > 0)
return res; // data or error is expected
if (res == 0) {
return -ETIME; // timeo in select
}
}
A resounding "no". kill -9 hurts it but it's invulnerable to everything
else.
Looking at the kernel code in select.c. I see it's implemented by poll
(I knew that). sys_select calls do_select and I can't for the life of
me see where anyone sets a signal mask. OTOH if all signals are
masked by default when syscalls are made (I don't know, but it seems
possible) then I can't see where interrupts are allowed again.
The man page for select says nothing about it being interruptible, or
not.
This has been in the back of my mind for months. I'm glad somebody
asked about it!
Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 07 2001 - 21:00:15 EST