[boost] Re: [network] An RFC - updated

From: Michel André (michel.andre_at_[hidden])
Date: 2005-04-22 09:27:08

Peter Dimov wrote:
> Michel André wrote:
>> Do you have specific reasons? Like interface simplicity,
>> implementation complexity?
 >
> Simplicity, mainly. If multiple dispatchers were present, how would you 
> use them to your advantage? The typical application loop would still 
> consist of polling all the dispatchers. 

Or having one thread polling one dispatcher and another one calling the 
other handling connections with different priority eg for one sake or 
another.

 > The intent of poll is to
> preserve the conceptual model of the current library, but allow the 
> client to be unaware of threading issues. Single threaded clients 
> typically have a loop that is a natural place for the net::poll call.

I think the idea of a poll or an dispatcer::dispatch is a great idea and 
gives the opportunity to write single threaded reactive servers or 
clients for that matter.

>> How do you stop the asynch polling threads started with
>> net::asynch_poll or isn't that needed?
> 
> 
> The library already supplies several 'cancel' functions, so something 
> similar could be used here as well (although I've never had a need to 
> stop a background dispatcher so I'm not sure whether this is an 
> essential feature.)

Maybe this isn't strictly needed, but I imagine some isssues could raise 
during shutdown, if the order isn't defined.

>> Why should delivery of notifications from net::poll only be on
>> operations started from that thread? This would divide threads to i/o
>> non i/o and I won't be able to post async op from non i/o threads. Or
>> am I missing some parts of the puzzle ;)
> 
> 
> I see that what I wrote is ambiguous. net::poll executes the pending 
> callbacks in the notification queue, regardless of the thread that 
> scheduled them. The actual callback invocations are made from the thread 
> that invoked net::poll.

Ok. So basically net::poll should be thread safe and I could use a 
thread pool dispatching io events by executing net::poll in a loop.

Do you envisione some way to control the threading policy for 
net::asynch_poll? Such as number or working threads or whatnot or should 
it be at the libraries discretion.

> The idea is to eliminate the need for locking and reentrancy in 
> single-threaded clients, not to filter callbacks based on the thread 
> that scheduled them.

Ok. And thats a fair goal thats needed.

/Michel