[chuck-users] Chuck Concurrency Best Practices

Stefan Blixt stefan.blixt at gmail.com
Sat Aug 30 06:01:48 EDT 2008

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;


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) {




...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.


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>

More information about the chuck-users mailing list