Messages in this thread |  | | From | Bernd Eckenfels <> | Subject | Re: Desperately missing a working "pselect()" or similar... | Date | Fri, 05 Oct 2001 22:37:15 +0200 |
| |
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?
> 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.
Greetings Bernd - 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/
|  |