On 11/1/05, Scott Woods <scottw@qbik.com> wrote:
----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Wednesday, November 02, 2005 10:05 AM Subject: Re: [boost] Active objects?
"Reece Dunn" <msclrhd@hotmail.com> 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?
In the presentation he gave reasons for needing to have the future<> and call wait() etc. In the end it seems to boil down to having a point to reliably catch exceptions and other errors. But he also mentioned clearly that it's just a concept they've been toying with and that they have no strong commitment to it.
Cheers.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Cory Nelson http://www.int64.org