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