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. I personally don't care much for the "standard" way of writing multithreading programs, because it quite error-prone. Other methods, like the one you propose and others such as the Join calculus, are less error-prone and often more expressive. But, operating systems and VMs provide "standard" threading models, so something like Boost.Threads can be a good implementation base for higher-level multithreading, distributed, and parallel programming styles.
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? Doug