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. Ad 1) this is currently not supported by boost thread, and given the rather controversial discussion about correct semantics in the past, it is unlikely to happen soon. Ad 2) This puts a lot of burden onto the user of the library. Interfaces also are likely to be different for various IO libs. Desirable would be a (free) function, say "alert(thread-id)" that is given the thread-id of B. When called by thread A, whatever is necessary to wake up the thread B will be done. The point is that my proposed library does not do the real actions, but only supply a framework that will allow the IO library to register a function to be called when it is time to break out of IO. To find out whether this is feasible I wrote a prototype implementation and an example to demonstrate the use of the interface. (Altough currently only available for MSVC.) My approach is two step. The first of which even might be interesting for a library on its own. 1) A "thdmbrptr" thread member pointer lib The intent of this library is to allow two threads to establish a shared memory space, without requiring the user code to pass any information. This basically does work like a thread local storage from inside the thread: boost::thread_member_ptr<myclass> pmyclass; All functions known from thread_specific_ptr are available, and so is semantics from inside the thread. Besides this another thread can get access to the data by: pmyclass[th]->foo(); where "th" is a thread id (or boost::thread*) and "foo()" is a function of "myclass". The lifetime of the myclass instance is managed by a shared_ptr. One reference is held by the thread (by means of a tss), a second is held by the boost::thread object that created the thread, and additional references might be held by other threads that obtained it by "*pmyclass[th]". 2) An "alert" lib The alert lib has two functions and a class object. alert(boost::thread* th) . . . to alert a thread bool alerted() . . . to find out (and reset) the alerted state of a thread class alerter . . . a class that will be instantiated on the stack. The constructor registers a (IO - ) lib defined function, The destructor unregisters this function. Some additional notes: I have been able to write a prototype implementation that 1) does not need any change to the current boost::thread 2) does not contain platform dependant code since it is built entirely on top of other boost libs. Altough it would by surely desirable to modify boost::thread to give a cleaner interface and improve performance. (Given the alert-ability of threads, a cancellation might later be built on top of it.) If it turns out, that there is interest in my proposal I will upload my files into the "vault". Thank you for your attention, Roland