On Fri, Aug 03, 2012 at 12:20:09PM -0700, Thomas DiModica wrote: > There are interesting implications for this, however. pthread_join becomes a > function that may eat a signal to cancel. The main implication is, > essentially, > that every occurrence of condition_wait becomes a call to hurd_condition_wait. > I don't know if any of the calls to condition_wait weren't cancellation > points for > good reasons. Secondly, would this conflict with the proper functioning of the > libraries? Does a utility that links to a hurd library have to declare itself > a > server to pthreads for the library to work properly (if the library expects > these > cancellation semantics)?
For any code unaware of this type, it would simply act as if cancellation was disabled. > PS. In timedwait, we dequeue the thread, but the cleanup handler (which is > always run) ensures that the thread is dequeued also. Is this necessary, or > just an artifact that is due to how all of the timed functions were > implemented? The timing of your question is interesting. My current work on fixing select has led me to introduce a hurd_condition_timedwait function in the cthreads library. It prove more difficult than I initially expected precisely because of the issues around the condition queue (they also apply to pthread_mutex_timedlock). In short, this is a bug. You can take a look at my work directly on the Hurd repository [1]. -- Richard Braun [1] http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=rbraun/select_timeout
