Re: [boost] [rpc/marshal] prototype rpc / marshal library using asio and serialization (and futures in the future?)

From: Jeff Garland (jeff_at_[hidden])
Date: 2007-05-03 19:48:13

Christopher Kohlhoff wrote:
> On Sun, 29 Apr 2007 13:56:12 -0700, "Jeff Garland"
> <jeff_at_[hidden]> said:
>> I'm not 100% sure, I haven't tried that feature of asio.  My guess is
>> that it's a little different in that there may be a relationship
>> between the io requests posted in the thread and where the callbacks
>> are processed....so you have to 'know in advance' how threads and
>> processing map.  That's different from a typical thread pool.  Anyway,
>> one of us will either need to try it or ask Chris :-)
> 
> Yep, Stjepan's correct. You can have a pool of threads calling
> io_service::run(), and all those threads are considered equivalent when
> it comes to invoking the completion handlers. I.e. the io_service will
> just pick any one of them to run the handler.

Ok, I think the docs might deserve just a bit of clarification on this point. 
  Right now it just says:

   Multiple threads may call the run() function to set up a pool of
   threads from which the io_service may execute handlers.

So are you also saying that io_service guarantees that the once a handler is 
displatched in a thread another request won't interrupt it?

Also, I think I was a bit thrown off by this part of the docs:

  The io_service guarantees that the handler will only be called in a thread
  in which the run() member function is currently being invoked. The handler
  may be executed inside this function if the guarantee can be met.

which now I'm really not sure I understand :-/

One of the 'interesting' side effects of this behavior, btw, is that you 
better not write any code where you do something like this:

   thread 1 -> a) cretate io_service, b) setup handlers, c) call run;
   thread 2 -> a) setup handlers, b) do other initialization c) call run;

In thread 2 the handlers will be 'immediately active' because thread 1 has 
called run already...so the callbacks might happen before the required stop b 
initialization -- it really needs to be done first.

Jeff