would it make sense to somehow chuck something to now for shred joining functionality? it always sort of made semantic sense to me that (using standard built-in functionality) the only way to pass time was to explicitly operate on now.
like myShred => now;
In this way you won't be able to spork multiple shreds in parallel. And BTW you can achieve the same result by simply invoking myShred's function without sporking a shred. It would be great to have an implicit children counter in class Shred and a method 'waitForChildren' which returns as soon as all child shreds are terminated. So it could look like this: spork ~ foo(); spork ~ bar(); me.waitForChildren(); (or even make 'waitForChildren' called implicitly?) What you think? ___________________ w31rd0
vs. me.join( myShred );
Its a bit convoluted, but the first way might convey the passage of time more explicitly and more symbolically. Not sure how a joinAll would be worked into this scheme, though.
spencer
On Jul 26, 2006, at 9:29 AM, Ge Wang wrote:
Hi!
The current way chuck works makes sense. But (and I don't know "the prober to do this in concurrent programming) I think it would make more sense to wait for child shreds to finish before terminating. This way a parent wouldn't have to worry how long the child is running, which I think is none of it's business.
Perhaps what we need is a Shred.join( Shred child ), which should let time advance until the child terminates, if ever. And maybe also a Shred.joinAll() that waits for all children shreds.
Best, Ge!