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: Ethan Tira-Thompson <email@hidden>
- Date: Thu, 29 Nov 2007 23:37:21 -0500
However, when I try to call pthread_mutex_unlock from the cleanup
function that results from the eventual pthread_testcancel, it
returns an error "Operation not permitted".
Sigh... I have to take this back — testing in a simplified piece of
test code does seem to work on both 10.4 and 10.5. So I'm not sure
what's going on there with my "real" code.
Is there any particular reason you don't do the semi-standard unix
method of using select() or equivalent on your socket together with
a pipe, and then write a byte to the other end of the pipe from
whoever wanted to stop the thread in the first place? No messing
with signals needed.
Unfortunately, I'm given an std::iostream for the input, so I can't
select on that :(
I suppose things could be re-engineered to pass a file descriptor (or
hacked to extract the file descriptor from the iostream), but that
doesn't solve the general problem for other blocking system calls
which aren't socket based (e.g. wait, sigwait, pthread_join, etc)
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.
I've been doing some more testing and will reply to myself in my
original thread with some updates/summary...
thanks,
-ethan
_______________________________________________
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