[CM] S7, reentrancy, and threads

Iain Duncan iainduncanlists at gmail.com
Tue Dec 24 10:57:35 PST 2019

Hi Bill, I'm hoping I could get a sanity check on the use case I have in
mind for S7 before I go too far, as I discovered it wasn't going to be
pretty with Chicken. I *think* it will be fine with S7, but I'd like to
make sure I'm not misunderstanding.

I want to embed S7 in a max external, which for those unfamiliar with the
max-sdk, means that it will be embedded in some C code, with hooks to run
at class instantiation time (ie shared across all instances of the object
in max), object instantiation time, and receiving message event callbacks.
Ideally, I'd like to make it max-like, similar to how the JS object works,
such that by default each s7 object in Max will have it's own isolated
scheme interpreter. So I think that means re-entrancy?

I'm not sure yet about threading. I *think* that the way max works, I don't
have to worry about two interpreters being called at once, but I might be
wrong there. It looks like from the docs like I don't have to worry about
that anyway, if I'm understanding the threadsafe example, am I correct

Finally, it would be dead cool if separate max objects could ask to share
the same scheme space. It looks to me like this might be possible with
environments. Is that reasonable? I.e. if I have calls to scheme
interpreters from different instantiations, but they both share an s7
pointer (declared in class space, as if in a static class member), and they
ask for the same environment in their call to evaluate, is it possible to
have these separate calls to scheme share data and affect each others
runtimes, including function definitions?

Apologies if any of these should be easily answered by the docs - I'm
working through them, but as a scheme newbie, I'm frequently unsure if I
understand them right. :-)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://cm-mail.stanford.edu/mailman/private/cmdist/attachments/20191224/2e41b42e/attachment.html>

More information about the Cmdist mailing list