[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