[chuck-users] Chuck Concurrency Best Practices
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
> 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
> 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
> 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:
> 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?
> PS: Love dynamic Arrays! Can't wait for those SC/Smalltalk-like array
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the chuck-users