I’m (re-)writing a library block that I’m using semaphores with, protecting the integrity of shared data within a multiprocessing environment. Wait times may vary between less than 1 millisecond and several seconds, or even more. Multiple processes may be waiting for the same semaphore too be freed.
I made a working implementation - it uses wait until (condition), which isn’t the most runtime-efficient block in the world though. I could free up runtime for other processes, replacing this by a test loop with a considerable time interval - at the price of extra wait time for the waiting process. Ideally I would like the script to continue after having received a message. Now Snap! has a when i receive hat block, but not an ordinary version - I wonder why not.
To get a kind of passive wait you may try the continuation, i.e. use a publish/subscribe pattern.
Register a continuation of the waiting scripts and fire it when data is available (at stream update).
I'm not sure if a continuation does not involve implicit yielding. There are pieces of information about the threading model of the but nothing seems to be definitive nor official.
IMHO Snap uses a single processor model. So the "warp" is effectively a global critical section with an emergency timeout of 500 ms.
However, the risk of concurrent modification is low, as the context switch occurs only at the specific instructions in the code.
, which would have been a bit problematic anyway, since the second block is a hat block, and libraries do not install hat blocks. Even worse … the continuation doesn’t work (perhaps because the script was stopped earlier).
So for now I’ll stick with my (sub-optimal) wait until solution for now - this is the application:
(it's call (promise) that may or may not take a very long time to complete)
I agree.
Most of the time, yes; still I can think of such cases. For library-purpose blocks I’m trying to reduce risks to a very higher degree, since I won’t usually be around if a future user runs into trouble.
You can say that again. Especially amazing: that stop (this script) is apparently ignored this way when the continuation is run! Once more you’ve proven to be a most inventive programmer, thank you! I’m going to try how this particular solution compares to wait for (condition).
If you don’t mind, I’m once more returning to the stream-with-upvar issue. As you may have read, bh warned me that with the approach I adopted from you (= replacing any external variable with its value) has its limitations. At first I thought this was not a big downside, but :I’ve since changed my mind. So I tried the opposite approach: replacing the upvar with an internal variable. To my frustration, I can’t get it to work:
Hmm .. yeah, I should have known. Apparently jens’ explanation didn’t make it all the way to my long-term memory, but I’m beginning to understand continuations a little better by now.
Regarding my request for help with replacing an upvar with a purely internal variable within a embedded script - if even you don’t know how to do it, it may be impossible. As a last resort: perhaps @jens knows?
Short explanation for jens
I am trying to (re)create a few blocks for the Streams library v.2, resembling list-HOFs - such as map (function) over stream (stream). The corresponding list-blocks have “magic rings”: if you press the ring’s right arrow,value, index, and list appear. I would like to have these at my disposal (with list replaced by the yet evaluated part of the stream, counting down from the current item), but I’ve got the impression that such is not feasible or otherwise undesirable. An alternative would be to use upvars that may be referred to within the embedded script, like in for (i) is (start) to (end) - however upvar run a high risk of getting messed up with deferred evaluation: between specification and evaluation, their values may be changed e.g. by other stream-HOF blocks using the same upvars. So I’ve been trying to replace an upvar by an internal variable of the HOF-block, but that isn’t working. Do you know if it’s possible at all; if so: how; if not: do you have a different suggestion? Thank you in advance!
but nothing seems to be definitive nor official.
