site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Anyway, select() DOES NOT restart which is the key point here. -Jamil _______________________________________________ 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... Thanks so much Steve for sending that test code. While I was using the signal() interface instead of the sigaction() interface I made changes to the code you sent along and it seemed to work in comparing and carefully rereading the following man page excerpt: If a signal is caught during the system calls listed below, the call may be forced to terminate with the error EINTR, the call may return with a data transfer shorter than requested, or the call may be restarted. Restart of pending calls is requested by setting the SA_RESTART bit in sa_flags. The affected system calls include open(2), read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on a communications channel or a slow device (such as a terminal, but not a regular file) and during a wait(2) or ioctl(2). However, calls that have already committed are not restarted, but instead return a partial success (for example, a short read count). I realized I was getting hung up because I was expecting select() to restart on a signal delivery Select DOES NOT restart but rather exits with an EINTR (which you catch). I had bypassed the error return in the case that a shutdown signal was sent and was not expecting an EINTR. This email sent to site_archiver@lists.apple.com