Re: [boost] Determining interest for a thread library extension to handle blocking situations

From: Aaron W. LaFramboise (aaronrabiddog51_at_[hidden])
Date: 2005-01-09 05:20:29

Roland Schwarz wrote:

> Currently the threading library does not support for handling situations
> where a thread might be blocked on IO, in a platform independant way.
> 
> While it is possible to write (low level) IO such as networking code 
> that has
> the ability to be unblockable, the lack of an uniform interface seems
> unfortunate.
> 
> Say thread B currently is blocking on a (third party) IO library. Now
> thread A needs to abandon thread B. How should this be done?
> Possible options are:
> 1) A schedules a cancel request to B
> 2) A calls a certain function of the IO library that, given a thread ID
>     is able to unblock the current operation.

I think there is a genuine need for a portable interface that provides a
way to implement "cancellation semantics."  I think this is a pattern
commonly needed in threaded code.

It's my impression that POSIX cancellation in C++ is still in a really
sorry state, and its unclear where this is going.  I don't know if there
are any implementations that have implemented cancellation for C++ to a
point that its really safe or usable.  (Does anyone know more about what
is happening with this?  Is anyone involved in the POSIX or C++
standards working on this right now?)

Also, Windows doesn't appear to have any native support at all for
gracefully shutting down a thread: TerminateThread() doesn't attempt to
do any sort of unwinding, and appears to have a tendancy to leak resources.

> My approach is two step. The first of which even might be interesting for
> a library on its own.

What do you think about merging adding this to the Boost.Thread library
rather than making it separate?  thread_member_ptr in particular appears
to nicely compliment the thread_specific_ptr.  It also appears that
implementation would be simplified if thread_member_ptr were part of
Boost.Thread.

> 1) A "thdmbrptr" thread member pointer lib

I really like this class, but I do think it needs a better name.

> 2) An "alert" lib

As mentioned above, I think something of this nature is needed.
However, I am unsure of the interface you're proposing.  I would like to
see more experience using the alert class in real-world code.  I need to
think about this some more.

> If it turns out, that there is interest in my proposal I will upload
> my files into the "vault".

I definitely think you should upload the files to the vault.

Aaron W. LaFramboise