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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-04-22 07:41:22

Michel André wrote:
> Peter Dimov wrote:
>>> This means we have one global dispatcher for the library (completion
>>> queue in asynch case). Isn't there a need to have several
>>> dispatchers to be able to group connections to several
>>> dispatchers/pollers.
>>
>>
>> You can probably guess that I think that the answer is no. ;-)
>
> Yep ;)
>
> 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. 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.

> 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.)

> 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.

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.