On Thu, 2008-05-29 at 16:46 -0700, Stephen Hemminger wrote: > On Thu, 29 May 2008 23:41:55 +0000 > Darren Hart <dvhltc@xxxxxxxxxx> wrote: > > > I find I need to be able to break out of the blocked state while waiting > > to acquire a pthread_mutex. I'm using PI mutexes and want to continue > > to do so. As I understand it, I can't use a signal to break out of the > > lock as the man pages states: > > > > "If a signal is delivered to a thread waiting for a mutex, upon return > > from the signal handler the thread shall resume waiting for the mutex > > as if it was not interrupted." > > > > and that pthread_mutex_lock will not return EINTR. I had considered > > using cond variables, but I don't think they will provide the same PI > > behavior (since the threads are not blocked on the mutex while awaiting > > the pthread_cond_signal - right?). > > > > I'm sure I'm not the first to want to do this, does anyone know of a > > common best practice for accomplishing such a thing? > > > > setjmp/longjmp? Stephen, Hrmm... I confess to not having made use of them before. I read up a bit, and don't see right off how they would help in this situation. I assume you're suggesting the longjmp be used in a signal handler while the thread is blocked on the mutex - where would it jump to, and how would I ensure the integrity of the pthread_mutex structure (which thinks my thread is waiting for it) ? -- Darren Hart Real-Time Linux Team IBM Linux Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html