From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-11-01 14:11:19
Reece Dunn wrote:
> Cory Nelson wrote:
>> I saw that presentation too, it is very impressive and I can't wait
>> to see what comes of it.
> Yeah, having active and futures support would make writing
> multithreaded apps a dream.
It _could_ make _some_ multithreaded apps easier to write. :-)
>> I would love to see something like this go into boost but somehow I
>> don't think it could be done elegantly without language and compiler
>> support. Definitely wouldn't complain if someone proved me wrong :)
> Active objects would be very hard to do *automatically* since the
> object is a thread (very neat concept), with the constructor, methods
> and destructor being processed as messages to the object's thread.
An active object can be implemented as a logical thread, although there
should be no need to serialize read-only operations. But a physical thread
per object would be impractical.
> However, the active lambda stuff could possibly be done as an
> extension of Boost.Lambda using Spirit/Phoenix sugar:
> future< int > = active<>[ _1 = _1 + 2 ];
This doesn't work; your active<> doesn't take any arguments, so you can't
use _1. It is possible to make this:
future<int> f1 = active( bind( f, 1, 2 ) );
future<int> f2 = active( bind( &X::f, &x, 1, 2 ) );
work. But the problem is that you must have a way to specify which functions
(or closures, or even combinations of functions and arguments) can be
performed in parallel and which need to be serialized by the "active runtime
engine". (In the example above, f(a,b) may call x.f(a,b) "inactively".)
This active business looks very similar to apartment-threaded COM, where the
COM support framework serialized the calls to the component. It probably
could be made to work on a language level, given a sufficiently smart
compiler and a heavily optimized runtime.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk