site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com -- Terry On Dec 3, 2008, at 6:53 PM, Steve Checkoway <s@pahtak.org> wrote: On Dec 3, 2008, at 2:46 PM, Jamil Weatherbee wrote: Glad I could help. -- Steve Checkoway _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... No system calls interrupted by signals restart _by default_ on modern UNIX systems. I think the original problem in the posted pseudo-code was either the bits in the FD_SET being cleared, or the use of a non-volatile global flag variable, which the compiler then optimized into a register load after which the contents were not changed in the loop control by the signal handler. As an historical note on signals, FreeBSD adopted (sorta) POSIX signal handler behavior around release 2.0, and this was picked up by CSRG for the BSD4.4-Lite release, and everyone who picked up much of that also picked up the non-restart behavior. The only exceptions to this are signal handlers established with sigaction() instead of signal(), and specifying the SA_RESTART flag to force historical 4.2/4.3BSD behaviour. Some implementations also support a bsdsignal() system call to support restart behaviour as a porting aid, if it is used in place of signal() (SVR4.2 is one such sytem). This is why you'll see a lot of very old BSD code (e.g. comp.unix.sources archives, etc.) use longjmp() in a signal handler in order to abort the signal restart behaviour (sometimes it is actually #ifdef BSD) that used to be default for BSD systems prior to the mid 1990s. On the minus side, it was infinitely easier to implement user space threads packages like sigsched and the original MIT pthreads, if you could be guaranteed system calls would restart after a non-terminal signal was delivered. Adoption of the SVR2/POSIX instead of the old BSD behaviour as the new default for everyone made a lot of jobs harder. Thanks so much Steve for sending that test code. Anyway, select() DOES NOT restart which is the key point here. Good to know. I don't think I've ever actually looked up which system calls get restarted before. This email sent to tlambert@apple.com This email sent to site_archiver@lists.apple.com