From: Jason Turner (lefticus_at_[hidden])
Date: 2007-03-07 14:08:56
On 3/6/07, Frank Mori Hess <frank.hess_at_[hidden]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On Tuesday 06 March 2007 16:54 pm, Jason Turner wrote:
> > It was only after setting out to implement the project did I realize
> > that this concept had been published a few years back under the name
> > "Active Object" (http://en.wikipedia.org/wiki/Active_Object) and there
> > are a couple of similar implementations floating around.
> I've written a little active object framework too. In fact, it was what I
> was working on which led to me getting quite sidetracked on thread-safe
> signals. But now that I'm wrapping that up, I should be able to release
> my code soon. It works, I just haven't released it because I haven't
> written any documentation yet. I basically just combined ideas from the
> active object paper by Lavender, et. al., the ACE implementation, and
> boost, and added some syntactic sugar. I didn't try to provide a full
> active object class like you did. I provide active functions, futures,
> method requests, schedulers, and it is up to the user to combine a set of
> active functions with a scheduler and a servant object to produce their
> own full active object.
Personally, I am less interested in the algorithmic side and more
interested in the non-intrusive active_object<> style wrapper, with
asynchronous return types. Either way, it seems this is an idea whose
time has come and I would love to see some implementation make its way
If your implementation is further along than my own and more generic,
I would be interested in providing help if you need it.
The next most obvious place for these concepts to go would be into the
realm of multiprocess and distributed computing. A project I was
working on at my last company would have benefited greatly by taking
the concepts of futures and the python reflection library. As it was,
adding new distributed methods and parsing the results, waiting for
return values, etc ended up being probably 1/3 of the code.