[chuck-users] Chuck Concurrency Best Practices

[Stefan Blixt]

One way to get around the "shreds killing their children" (oh my God the
children!) problem could be to have some main sporker shred that's always
running and then use a queue and an event like this:

Event sporkEvent;

sporkableQueue;


fun void sporker() {

Sporkable @ sporkable;

while(true) {

sporkEvent => now;

sporkableQueue.popFirst() @=> sporkable;

while (sporkable != null) {

spork ~ sporkable.main();

}

}

}


spork ~ sporker();


fun void sporkShred(Sporkable @ sporkable) {

sporkableQueue.addLast(sporkable);

sporkEvent.signal();

}



...so instead of sporking directly you call sporkShred(sporkable), some
instance of a subclass of Sporkable with a suitable main() implementation.
Of course you need to implement the queue as well.


/Stefan

On Sat, Aug 30, 2008 at 5:28 AM, mike clemow <gelfmuse at gmail.com> wrote:

> Actually, I should tell you all that I took a look at my code from the past
> week and it's a heinous example of software design.  While I'm rewriting
> this travesty, I leave open the question about methods of managing
> concurrent processes in Chuck.
>
> Cheers,
> Michael
>
>
> On Fri, Aug 29, 2008 at 7:01 PM, mike clemow <gelfmuse at gmail.com> wrote:
>
>> Hi everyone,
>>
>> So, I've been struggling to find a method to leverage the concurrency
>> model in Chuck and I keep running up against the same issue: my guts tell me
>> to do things that I can't do because of fact that child processes are alive
>> only as long as the parent and the fact that objects are only passed by
>> reference.
>>
>> Let me unpack this for you.  I'm building a granular synthesis class
>> library for Chuck.  Most everything is being cast as one of two types of
>> objects:
>>
>> 1) Forkable - a process that takes parameters and can be run or sporked
>> 2) Forker - an object that knows how run a process and will fork it out
>> for you.
>>
>> In order to get over the fact that functions are not (yet) datatypes in
>> Chuck which can be passed to other functions, I'm basically following the
>> example that Kassen, Mike, et al. were discussing in this forum topic:
>>
>> http://electro-music.com/forum/viewtopic.php?highlight=functor&t=23546
>>
>> My problems always seem to rise from the fact that every Forker (whose job
>> it is to fork a process) also has to be aware of how long that process is
>> going to take or else run the risk of dying before it's child has
>> completed.  This leads to infinite passing of responsibility for time and
>> every Forker seems to also need to be a Forkable and have it's own Forker,
>> et cetera ad inifinitum.  At higher and higher levels of abstraction,
>> finding the duration of a process BEFORE it runs and figuring out how to
>> handle it, is requiring more and more analysis and feels...  for lack of a
>> better word, "wrong" to me.
>>
>> This is compounded by the fact that the objects I'm passing into these
>> functions (methods of other objects) can only be passed by reference and
>> it's increasingly difficult to set-and-forget these processes, since they
>> constantly reference other global objects.  The passing by reference is
>> fine, but I find myself wishing I had the choice to make a copy.
>>
>> Now, it's entirely probable that I just haven't caught on yet and am going
>> about this process in a completely backward way.  Does anyone here run into
>> similar issues and (even better) have good methods of avoiding them?
>>
>> One idea I have considered is to make a Forker a looping process that
>> receives Events as input, rather than an object with methods.  As this would
>> require a(nother) complete re-write, I'm stalling.  ;-)
>>
>> So, how do you manage your concurrent processes in Chuck?
>>
>> Cheers,
>> Michael
>>
>> PS: Love dynamic Arrays!  Can't wait for those SC/Smalltalk-like array
>> methods!
>>
>>
>> --
>> http://semiotech.org/wp-prod/
>> http://semiotech.org/michael
>>
>
>
>
> --
> http://semiotech.org
> http://semiotech.org/michael
>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>
>


-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080830/60a61723/attachment.htm>