[chuck-users] Stopping and restart shreds
Perry R Cook
prc at CS.Princeton.EDU
Wed Jul 26 13:07:12 EDT 2006
It would add to our "overloadation" but I don't think
it makes sense in that now deals with time, be it
deterministic or asynchronous (events).
PRC
On Wed, 26 Jul 2006, Spencer Salazar wrote:
> 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;
> 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!
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
More information about the chuck-users
mailing list