[chuck-users] Chuck Concurrency Best Practices

[Stefan Blixt]

This solution could be written more prettily if there was some way to wait
on several events, or some more general condition, like so:
(sporkableQueue not empty) => now;

I run into this every now and then.

/Stefan

On Sat, Aug 30, 2008 at 12:01 PM, Stefan Blixt <stefan.blixt at gmail.com>wrote:

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



-- 
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/11bd0aea/attachment.html>