[chuck-users] Chuck Concurrency Best Practices

mike clemow gelfmuse at gmail.com
Fri Aug 29 23:28:23 EDT 2008

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.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20080829/fea281a5/attachment.html>

More information about the chuck-users mailing list