On Wed, 23 Dec 2009, Carlos O'Donell wrote: > On Tue, Dec 22, 2009 at 5:05 PM, John David Anglin > <dave@xxxxxxxxxxxxxxxxxx> wrote: > >> I think we need to step back from the edge and ask ourselves what > >> Tcl_WaitForEvent() is trying to do with the locks. > >> > >> Do you know? > > > > In unix/tclUnixNotify.c: > > > > #ifdef TCL_THREADS > > /* > > * Place this thread on the list of interested threads, signal the > > * notifier thread, and wait for a response or a timeout. > > */ > > There will never be a timeout if you call pthread_mutex_lock as the > underlying operation. So this comment is a bit odd? The wait is done by Tcl_ConditionWait. It uses pthread_cond_wait if timePtr is NULL, otherwise it uses pthread_cond_timedwait(pcondPtr, pmutexPtr, &ptime). Do these work holding a lock? Any chance that these try to take a lock? It sems like bad coding to do a wait holding a lock. In any case, I don't think this is the problem. As you noted, the lock is held by the other thread. The return pc is beyond Tcl_WaitForEvent. The only users of the notifierMutex mutex are in tclUnixNotfy.c. The only interesting thing done holding the notifierMutex mutex in code after Tcl_WaitForEvent is to call Tcl_ConditionNotify. It calls pthread_cond_broadcast if the condition pointer isn't NULL. Could this deadlock? It's hard to see how it could since the mutex doesn't seem to be involved. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
