[CM] Question about threading and s7

[Iain Duncan]

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.

iain

On Thu, Sep 24, 2020 at 6:34 PM Iain Duncan <iainduncanlists at gmail.com>
wrote:

> Hi folks, I'm hoping someone can help me out with a question around S7.
>
> 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....
>
> 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.
>
> 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.
>
> 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.
>
> Any thoughts most welcome!
> iain
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/pipermail/cmdist/attachments/20200924/667d68e8/attachment.html>