RE: [boost] Future of threads (III)

From: scott (scottw_at_[hidden])
Date: 2004-02-12 20:15:19

> [mailto:boost-bounces_at_[hidden]]On Behalf Of Douglas Gregor
> Sent: Friday, February 13, 2004 11:56 AM

> On Thursday 12 February 2004 05:28 pm, scott wrote:
> > so, is there room for 2?
> 
> Sure. One "obvious" question is whether your threading 
> library would need to 
> be completely separate, or whether it should be implemented 
> as a layer on top 
> of something like the existing Threads library.

hmmm, yes. had wandered down this road. you could say that
i stubbed my toe on a small rock with "join" written on it.
the whole issue of error handling around join was very relevant.
exceptions in the alternate model are caught (or not ;-)
within the object that "is" the thread. there is not the
same need to transfer error information between threads
out of some sense of righteousness (you gave me this code
to run, now you eat this exception).

but that is somewhat convenient. i dont have any real case
for not building on top of boost::threads. i would wonder
about losing touch with the available threading primitives.
its hard enough making it work without having to work through
an intermediary. but hiding the specifics of threads is
a major benefit of boost::threads so i will (head down)
look into this.

the result wouldnt be an "alternate" model though :-)

> > very briefly, the boost model treats threads as a resource 
> (fair enough
> > to :-) and submits code fragments for asynchronous execution. in the
> > alternate model, threads come about as a consequence of 
> instantiating
> > final (a la java) objects. the distinguishing attribute 
> being that threads
> > only
> > run code that is "part of themselves" rather than code 
> being submitted
> > from "outside". execution of the code is initiated by sending of a
> > message (within my vocabulary that is actually a signal). 
> the message
> > can contain arbitrary data.
> 
> This reminds me of the actor model of distributed 
> computation. If you are 
> familiar with actors, could you briefly compare/contrast your 
> approach 
> against them?

i know of uml's actor but not sure if that's the same thing.
and my knowledge of uml is so lame i suspect i shouldnt attempt
any analogies.

was there some specific aspect of alt-threads that needed
elaboration (yeah, like everything :-) or were you suggesting
a new direction for me to check out?

cheers,
scott