Re: [boost] asio review extended till Dec 30th

From: Darryl Green (darryl.green_at_[hidden])
Date: 2005-12-29 21:42:32

Christopher Kohlhoff wrote:
> 
> The reactor lock is held when making I/O calls, but these are
> non-blocking.

Non-blocking in some sense - but you can't rely on it not being a 
preemption point/taking another (kernel) lock etc. I do agree it isn't 
as bad as making a blocking I/O call with a lock held of course.

> It is also on my to-do list to investigate
> separating the reactor wait from the subsequent I/O calls so
> that it can scale better across multiple CPUs (i.e. the I/O
> calls on different sockets can be made concurrently).

warning - another rant on need to expose policy follows - stop reading 
if you are sick of it....

The reactor-based async I/O emulation  basically does user/kernel buffer 
copies in the I/O call. It would seem brave to assume an advantage on 
all systems from trying to utilize multiple CPUs for that, considering 
the potential cost of dispatching to another thread + rescheduling when 
the reactor waits again vs just doing the copy. Clearly this shouldn't 
be used on a uniprocessor at least. I guess if the dispatching resulted 
in the I/O and subsequent handler running in the same thread without 
another crossing of thread boundaries this would be close to performance 
neutral at worst wrt the current system, but I can't really see how to 
do that effectively (allowing for locking dispatch etc). Doesn't the 
current dispatcher use a leader/followers approach so that the I/O will 
be done by the thread that just woke-up from the select/epoll/whatever? 
Thinking about that - why would that thread need to hold a lock while 
doing the I/O anyway?

Basically this is another feature that should encourage user selectable 
policy in the public interface of the library. A hugely complex set of 
policies/options to get something reasonably scalable to work isn't 
going to be widely appreciated, but I can't see why some sensible 
defaults can't be assembled/packaged/selected easily.

On the threading issue in general, I do see considerable merit in an 
async io system that includes the mechanisms needed for message 
passing/deferred execution integrated with the io handling so as to 
allow "background" processing (vs reactive handlers). As you mentioned 
elsewhere, the locking dispatcher has the potential to avoid explicit 
locking in user code. The combination of these facilities surely 
supports the view that the threading policy applicable to a particular 
use of asio is not necessarily the same threading policy applicable to 
other components used in the same app. This clearly isn't an issue for 
asio alone, but does suggest that even when threading is used, asio 
should allow more fine-tuning than using a boost-wide or 
application-wide build option.

Regards
Darryl Green.
> 
> Cheers,
> Chris
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 
> 
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.9/216 - Release Date: 29/12/2005