On Fri, Oct 05, 2001 at 10:36:53PM +0200, Bernd Eckenfels wrote:
> In article <3BBDD37D.56D7B359@isg.de> you wrote:
> > Without a proper pselect() implementation (the one in glibc is just
> > a mock-up that doesn't prevent the race condition) I'm currently
> > unable to come up with a good idea on how to wait on both types
> > of events.
>
> Isnt select() returning with EINTR?
The select system call doesn't return EINTR when the signal is caught
prior to entry into select.
The problem is if you have a select loop and small signal handlers
setting flags for the loop, a signal could come in after the flag is
tested but before select is called. Instead of acting on this signal
right away, the process blocks in select.
The pselect system call offers a solution. The process blocks signals
in the select loop; pselect unblocks those signals and does a
select. The race condition mentioned earlier disappears: the signal
that arrives after the flag test is blocked. The pselect system call
unblocks the signal, so the deferred signal acts just like it arrived
while the process is blocked in select.
> > A somewhat bizarre solution would be to have the process create
> > a pipe-pair, select on the reading end, and let the signal-handler
> > write a byte to the pipe - but this has at least the drawback
> > you always spoil one "select-cycle" for each signal you get
>
> Well, you can use the pipe instead of the signal. What kind of signal do you
> try to trap? Looks like you want to do critical high load stuff with a
> signal.
He just wants to handle signals properly 100% of the time.
-
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 : Sun Oct 07 2001 - 21:00:39 EST