| |||||||||||||
The new pselect() system callThe new pselect() system callPosted Mar 31, 2006 4:24 UTC (Fri) by hppnq (guest, #14462)In reply to: The new pselect() system call by clugstj Parent article: The new pselect() system call Mmmh, I like the fact that system calls can be interrupted. :-) Signals can be used for notifying process groups asynchronously of some event, for instance, which is likely to be a bit more tricky to do with select(). Yes, this is ancient Unix, but so is the concept of the tty. Using select() as a replacement for signal handling is a quite tricky hack that only solves one specific problem and creates a couple of others, so I'm glad work is being done to implement the appropriate, standard interface. :-)
(Log in to post comments)
System Call Interruption Posted Mar 31, 2006 13:30 UTC (Fri) by clugstj (subscriber, #4020) [Link] System call interruption is not portable. Some UNIXes will restart some system calls after they handle the signal, some won't. Yes, signals are OK in non-threaded applications, but when the application uses threads, the race-condition nightmare begins.
System Call Interruption Posted Mar 31, 2006 15:23 UTC (Fri) by hppnq (guest, #14462) [Link] Portability is not an issue when your system call is actually interrupted. :-)The complexity that arises from mixing signals and threads is only justified if you have specific reasons to implement it like that. By default, a multi-threaded process acts the same as a non-threaded process when interrupted. So, unless you have specific reasons for defining per-thread signal masks (which is possible), there's nothing special about the multi-threaded case.
|
|||||||||||||