[mailto:boost-bounces@lists.boost.org]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