Boost logo

Boost :

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.

Darryl Green.
> Cheers,
> Chris
> _______________________________________________
> Unsubscribe & other changes:

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at