Re: [boost] [asio][tr2] rough draft of TR2 proposal

From: Simon Meiklejohn (simon.meiklejohn_at_[hidden])
Date: 2006-08-14 17:46:41

> - I need some language to talk about threads and their call
>   stacks. Example: a handler object scheduled for execution
>   using io_service.post() will only be invoked from a thread
>   that is currently inside a call to io_service.run().

I see this requirement as a means of expressing constraints on
a more general concept of execution context. Different implementations
of execution context would carry out the post using different
strategies 

e.g. 
thread pools, 
new thread per post(), 
visitation of the execution context by a thread as work arrives 
(e.g. servicing execution in a shared system thread like the win32 message pump)

If the programmer could specify precursor code to execute before 
any posts are serviced, and also before and after each individual
service that would be good. 

void win32_com_precursor()
{
    CoInitialise(/*params*/);
}

void logging_precursor()
{
   log("execution start");
}
void logging_postcursor()
{
   log("execution stop");
}

// setup code
// executed before first post() is actioned.
io_service.addexecutionprecursor( &win32_com_precursor ); 

// executed before and after each post() is actioned
io_service.addexecutionprecursorpercall( &logging_precursor );
io_service.addexecutionpostcursorpercall( &logging_postcursor );

Such pre/postcursors could be a way of obtaining the memory barrier
conditions Chris mentions (i.e. grab a mutex, release a mutex). They
could also be expressed as a type, of which an instance must be 
constructed before execution proceeds.

This style would lend itself to a more declarative way constructing 
execution contexts that might lend itself to a language centred 
implementation, rather than the above, which imposes a fair 
amount of boilerplate on the programmer. Not sure what that code would
look like.

Hope this isn't too wildly off topic

Simon