Re: [boost] Active objects?

From: Scott Woods (scottw_at_[hidden])
Date: 2005-11-01 21:00:36

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Wednesday, November 02, 2005 10:05 AM
Subject: Re: [boost] Active objects?

> "Reece Dunn" <msclrhd_at_[hidden]> writes:
>
> > 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.
> >
> >>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)
>
> Also a very old concept.  See Simula.  Kristen Nygaard would be
> pleased.
>
> However, it sounds a lot like the COM "apartment model," which I've
> never had the pleasure to use, but whose usability I recall my
> colleagues complaining bitterly about.
>

Huh. Had thought the "active object" term had originated from work by D.
Schmidt.
Not too many complaints about his version of things, even if working with
some
implementations (CORBA) can be unwieldy.

H. Sutter's version looks nice. The idea that calls on an object can be
queued for
execution at some later time is useful. Successfully hiding the details
would be cute.

I hope it's fair to also say that it's not a solution to the nasty async
problem that I
typically run into.

Active objects (a la Sutter) appear to be reinforcing the standard "call"
model
over async activity. This is good because it is familiar to us. Symmetric
interaction
between groups of peer objects is a different model of operation. Any object
can "call" any other object and there is no "return" (i.e. future). Most of
my
async-programming problems seem to fall into the latter category.

In summary, Mr Sutters AOs would deliver a slick solution to a certain class
of application. I'm guessing it's not intended as the "final" solution to
all
async development?

Cheers.