Messages in this thread |  | | Subject | Re: [OT] Interrupting select. | From | Olaf Dietsche <> | Date | 04 May 2001 22:59:20 +0200 |
| |
Hi,
"Peter T. Breuer" <ptb@it.uc3m.es> writes:
> "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. [snip] > 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!
I'm not really sure, what you're asking for. Select() is interruptible.
But: if you have multiple threads, the signal may be delivered to any thread. So, what you may see, is, that the signal is delivered to a thread, but the signaled thread is not the thread waiting in the select() call.
Therefore it _seems_, as if select() is not interruptible, but it surely is.
Regards, Olaf. - 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/
|  |