Re: pthread_mutex_unlock not permitted in signal handler?
Re: pthread_mutex_unlock not permitted in signal handler?
- Subject: Re: pthread_mutex_unlock not permitted in signal handler?
- From: Eric Gouriou <email@hidden>
- Date: Thu, 29 Nov 2007 22:22:58 -0800
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.
Eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden