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

From: Roland Schwarz (roland.schwarz_at_[hidden])
Date: 2005-01-08 15:36:11

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