<div dir="ltr">Actually, I should tell you all that I took a look at my code from the past week and it&#39;s a heinous example of software design.&nbsp; While I&#39;m rewriting this travesty, I leave open the question about methods of managing concurrent processes in Chuck.<br>
<br>Cheers,<br>Michael<br><br><div class="gmail_quote">On Fri, Aug 29, 2008 at 7:01 PM, mike clemow <span dir="ltr">&lt;<a href="mailto:gelfmuse@gmail.com">gelfmuse@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div dir="ltr">Hi everyone,<br><br>So, I&#39;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&#39;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.<br>

<br>Let me unpack this for you.&nbsp; I&#39;m building a granular synthesis class library for Chuck.&nbsp; Most everything is being cast as one of two types of objects: <br><br>1) Forkable - a process that takes parameters and can be run or sporked&nbsp; <br>

2) Forker - an object that knows how run a process and will fork it out for you.<br clear="all"><br>In order to get over the fact that functions are not (yet) datatypes in Chuck which can be passed to other functions, I&#39;m basically following the example that Kassen, Mike, et al. were discussing in this forum topic:<br>

<br><a href="http://electro-music.com/forum/viewtopic.php?highlight=functor&amp;t=23546" target="_blank">http://electro-music.com/forum/viewtopic.php?highlight=functor&amp;t=23546</a><br><br>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&#39;s child has completed.&nbsp; This leads to infinite passing of responsibility for time and every Forker seems to also need to be a Forkable and have it&#39;s own Forker, et cetera ad inifinitum.&nbsp; 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...&nbsp; for lack of a better word, &quot;wrong&quot; to me.<br>

<br>This is compounded by the fact that the objects I&#39;m passing into these functions (methods of other objects) can only be passed by reference and it&#39;s increasingly difficult to set-and-forget these processes, since they constantly reference other global objects.&nbsp; The passing by reference is fine, but I find myself wishing I had the choice to make a copy.<br>

<br>Now, it&#39;s entirely probable that I just haven&#39;t caught on yet and am going about this process in a completely backward way.&nbsp; Does anyone here run into similar issues and (even better) have good methods of avoiding them?<br>

<br>One idea I have considered is to make a Forker a looping process that receives Events as input, rather than an object with methods.&nbsp; As this would require a(nother) complete re-write, I&#39;m stalling.&nbsp; ;-)<br><br>So, how do you manage your concurrent processes in Chuck?<br>

<br>Cheers,<br>Michael<br><br>PS: Love dynamic Arrays!&nbsp; Can&#39;t wait for those SC/Smalltalk-like array methods!<br><br><br>-- <br><a href="http://semiotech.org/wp-prod/" target="_blank">http://semiotech.org/wp-prod/</a><br>
<a href="http://semiotech.org/michael" target="_blank">http://semiotech.org/michael</a><br>

</div>
</blockquote></div><br><br clear="all"><br>-- <br><a href="http://semiotech.org">http://semiotech.org</a><br><a href="http://semiotech.org/michael">http://semiotech.org/michael</a><br>
</div>