site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com Eric _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... On Nov 29, 2007, at 8:37 PM, Ethan Tira-Thompson wrote: I did realize however, that read() has a EINTR error return code, so instead of trying to unlock within the signal handler itself, perhaps I could just make the handler a no-op, and then test for the error code following the read(). However, in its infinite wisdom, the system resumes the read and doesn't bat an eye at the signal coming and going, so this idea never actually interrupts the read(), nor causes the unlock and exit to occur. If you are using sigaction() to establish the signal handler, it's time to double-check that SA_RESTART is _not_ being set. --- 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). --- However the EINTR behavior is specified for read(2), I don't know if one can get iostream::read() to avoid calling read(2) again upon receiving that errno. This email sent to site_archiver@lists.apple.com