User: Password:
|
|
Subscribe / Log in / New account

The new pselect() system call

The new pselect() system call

Posted 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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds