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