[chuck-users] implementing a "wait for signal with timeout"

[Hans Aberg]

On 8 Jun 2009, at 19:53, Robert Poor wrote:

> In real-time music making, sometimes you want to wait for a signal  
> (e.g. event.broadcast()) OR for a specific time to elapse, whichever  
> comes first.  I've implemented ways to do this, but I'm not really  
> satisfied with the code.
>
> Here's the problem: Lets say that your music is slaved to a  
> metronome, and the metronome is allowed to change speed.  You want  
> your music to stay sync'd to the metronome.  If you simply do:
> 	now + (1/tempo)::second => time next_beat;
> 	next_beat => now;
> 	play_note();
> you'll be in trouble if the metronome speeds up while you're  
> waiting: your note will be late.  The fundamental problem is that  
> once you execute "next_beat => now;", you're committed to waiting  
> and there's now way to break out of it, short of killing the  
> thread.  The problem with killing the thread is that you leak 88K  
> with each thread (!!!).
>
> So here's the programming challenge: how would you implement a "wait  
> for signal with timeout" that will block until it gets a signal OR a  
> specified time has elapsed?  Since each thread costs 88K in non- 
> reclaimed memory, you may create threads, but your solution must re- 
> use them.

You might check out the noteoff() function I implemented here:
   https://lists.cs.princeton.edu/pipermail/chuck-users/2009-May/004183.html

There is a similar problem of future event rescheduling: a future  
disconnect, that should be canceled, if there has been a new note-on.  
So the future event gets a thread of its own, and when it awakens, it  
checks if there has been a rescheduling - if so, it just cancels the  
event.

As 'chuck' does not have event scheduling and kill-threads was not  
intended for massive use, this seems to be the only way. But it works  
just fine.

   Hans