<div dir="ltr">Another option I'm thinking of is giving the users a way to expressly send messages to one or the other thread within the object (ie by requesting promote or defer) and then letting them protect the data sensibly themselves. I'm not sure how this is normally done in Scheme though.<div><br></div><div>iain</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 24, 2020 at 6:34 PM Iain Duncan <<a href="mailto:iainduncanlists@gmail.com">iainduncanlists@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi folks, I'm hoping someone can help me out with a question around S7.<div><br></div><div>In Max/MSP, when setup for live use there are (generally) two threads of operation, with the high-priority/dsp thread able to interrupt the low/GUI. If one doesn't do anything special, this means a max external (such as my Scheme-for-Max) could be receiving messages in both: low for things originating from a GUI action, high from metronomes or midi input. I assume that I should not expect all to be ok if I have one instance of an s7 interpreter, which could be accessed from either thread, and it could get interrupted part way through an eval operation to run another eval in another thread that may access the same data. IE there's no magical thread protection baked into S7 that I don't know about....</div><div><br></div><div>I'm wrestling with how to deal with this correctly. One option is to allow users to designate an s4m instance as always-high or always-low, basically saying if you need to mix low and high priority you should treat it like an actor model and have two interpreters that message each other and share data through some non-scheme shared data structure (like max buffers or tables). This might be ok because there is a way for me to insure incoming max messages from any thread are either promoted or demoted. </div><div><br></div><div>I suppose another option is to get into critical sections, but I can't see how that make sense if we don't want low priority actions to have the chance of locking out high ones. </div><div><br></div><div>Strangely, I have not had any issues yet. But I presume that just means I've been lucky. Cycling 74 does not (anymore) allow the javascript object to work in both threads, and I'm thinking it must have been around thread stability issues.</div><div><br></div><div>Any thoughts most welcome!</div><div>iain</div></div>
</blockquote></div>