Hi @semiquaver.
NamedSingleton lives here for the moment:
But I am not using NamedSingleton for UnixCmdQueue.
I was using it for Queue though.
Hope this answer your question.
Iannis
Hi @semiquaver.
NamedSingleton lives here for the moment:
But I am not using NamedSingleton for UnixCmdQueue.
I was using it for Queue though.
Hope this answer your question.
Iannis
Here’s the same solution using the Deferred
object (GitHub - scztt/Deferred.quark), which I think I wrote as a replacement for Condition
when this topic came up a few years ago? This also does per-thread timeouts (though I think maybe it’s better to think about them as “per-wait-timeouts”, since that’s how it looks from an API perspective). This doesn’t allow for changing timeout as your setTimeout
looks like it’s doing, but IMO changing timeouts of waiting Conditions seems like it could be an anti-pattern anyway (at the very least, an opportunity for hellishly complex behavior…).
I think the main difference from Condition
is that Deferred
enforces a strong value semantics: you more or less have a guarantee that result = deferred.wait()
with an asynchronous result, will behave exactly the same as result = { /* calculate result synchronously */ }.value
- e.g. if there was an error, that error is thrown in your thread as if it had occurred there etc.
(
fork {
var cond = Deferred();
var result;
thisThread.clock.sched(0.5, {
if(0.5.coin) {
cond.value = 1;
};
});
try {
"Result: %\n".postf(cond.wait(1));
} {
"Timed out".postln;
}
};
)
I’ve opened a draft PR for a new condition variable class building on the ideas that grew out of what @jamshark70 and I discussed earlier: Add CondVar by brianlheim · Pull Request #5394 · supercollider/supercollider · GitHub. If people are interested, I’d appreciate getting a look over. I found this code really difficult to get right – at least, right as far as I can tell.