Proposal: Condition timeouts

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;		
	}
};
)

@scztt quark looks useful!

…humble request for a help file or examples one day!

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.