Hi Chris! On 10/19/06, Christopher Kohlhoff <chris@kohlhoff.com> wrote:

Dean Michael Berris wrote:

...

The question would be whether there will be (or whether there already is) a "generic" active object implementation? We've found that Boost.Asio's io_service is a good scheduler/queue and using a futures wrapper for the result types.

An alternative to having an io_service per active object is to have multiple active objects share a single io_service (would these be called "semi-active objects"?).

This sounds alright, though the problem I see with this is that when we profiled a single io_service solution as compared to one io_service per active object, we saw significant improvements (on multi-core systems) on the one io_service per active object. Of course, this is a case-to-case basis analysis, and it shouldn't be hard to make this work semlessly. For example, a set of active objects can use a single io_service while another set of objects can use another one.

If you also use a strand per active object, then the active objects can even share an io_service with a thread pool calling io_service::run(). The strand will ensure that the operations for a single active object don't execute concurrently.

This sounds like a good approach indeed. I haven't tried strands yet, but this does seem to make a lot of sense. Although we use thread locking primitives even on the active objects (which I thought were necessary without using strands). -- Dean Michael C. Berris C++ Software Architect Orange and Bronze Software Labs, Ltd. Co. web: http://software.orangeandbronze.com/ email: dean@orangeandbronze.com mobile: +63 928 7291459 phone: +63 2 8943415 other: +1 408 4049532 blogs: http://mikhailberis.blogspot.com http://3w-agility.blogspot.com http://cplusplus-soup.blogspot.com