> -----Original Message----- > From: Sam Varshavchik > Sent: Saturday, February 03, 2007 3:43 PM
> > The more vaguely interesting thing is that > > pthread_cond_destroy() *is* > > returning EBUSY. > > Yes, that's the interesting part. I'll fix the pthread error > checking, but the EBUSY return suggests an underlying problem. > > The condition variable gets waited on by the worker thread. > The same worker thread that gets cancelled, and then joined, > right before this pthread_cond_destroy call. By the time > pthread_join returns, the worker thread should be gone, and > it should not be waiting on the condition variable any more. > So, I don't understand the reason for the EBUSY error, either. Ok, as far as I can see, this is the situation: [ Apologies if this all is obvious or trivial... ] The condition variable tracks sequence numbers of the last use and the last wakeup; these are pure sequence numbers, and unrelated to any threads or anything else: the each wait increments the use count, and each wakeup increments that count. When a thread is woken, the first thing it does is increment it's wakeup sequence. But if it is cancelled instead, it dies before it can do that, leaving a discepancy between the wakeup and usage sequences, which pthread_cond_destroy interprets as indicative of a thread still waiting. However, since the condition variable (gocond) is unique to each thread, and as you say the thread has been cancelled and joined, there cannot be a thread waiting. Looking at the ChangeLog for glibc-2.5, I see that the test in pthread_cond_destroy (which generates the EBUSY) was added in August 2004, which seems to have been with released version glibc-2.3.3; sometime shortly prior to that the test didn't exist, so pthread_cond_destroy never returned EBUSY. Now, as it happens, as far as I can see all that pthread_cond_destroy does is safely transition the variable into a state where threads won't wait on it. It doesn't release any resources or do anything fancy. In Courier's use, since the condition variable are used for master/slave type synchronization, and it's the master that's just killed the slave, I propose to treat EBUSY as a successful return value. I confess that I can't see how pthread_cond_destroy is really supposed to be used, but then again most of the discussion of the thing implies that on Linux it's typically something of a no-op. Comments? Malc. ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
