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: Lassi Tuura <email@hidden>
- Date: Fri, 30 Nov 2007 00:07:37 +0100
Hi,
Is it *at all possible* to unlock a mutex following the
interruption of a thread on Tiger? (I haven't tried this on
Leopard yet -- since I don't need to do the signal hack there,
hopefully this is moot) Basically, I'm reading from a socket, and
need a way to kill the thread if there's no response. But I also
need to maintain a lock on the socket while I'm waiting for a
response so other tasks don't try to send their own queries. I'm
polling relatively frequently, so I don't want to have to take the
lock, launch a new thread, and monitor the other thread every
time. (this is a real-time task with a hardware device)
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.
On a related note, don't use pthread_mutex_* from a signal handler if
you use the same mutex outside signals in the same thread. You may
not be allowed to enter pthread_mutex_* twice in the same thread,
even if the mutex is recursive. Let's say the socket reader quits at
just the right time and enters pthread_mutex_*, and just then your
signal arrives, and also attempts to execute pthread_mutex_*. Now
your program would have entered the mutex twice in the same thread.
On some systems this results in a failure or a dead-lock.
Lassi
_______________________________________________
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