🚀 go-pugleaf

Alberto wrote:

>> Ok, so now all of a sudden, we're working under interrupts.

>The interrupts are those generated by a sound card, and being taken care of
>by the sound card driver. After each interrupt, the Windows MME system posts
>an event control block which one of my threads is waiting upon.

Ok, so now not interrupts, but events.
(Next you'll tell me it's not events, but something else, so why don't
you just come out and tell us exactly what API function(s) you are
trying to use.)

>The thread is so awakened, does what it has to do, and goes back to wait for
>the next event.

"does what it has to do" could entail placing the info in a FIFO
buffer and returning.  The rest is as I described in the last message:
a workng thread that varies the complexity by the number of items in
the buffer.

Alternative (but same idea): if the events overlap, reduce the
complexity.
Have 2 (or more) threads waiting for the event, and one "busy" flag
(mutex).
Thread 1 is triggered, and sets the flag (reset upon completion).
Thread 2 is triggered, and sees flag is set, so waits for flag to
clear, and steps down complexity (probably a global value so it
"sticks")..
If a thread starts and doesn't see the "busy" flag, it could then step
up a notch (possibly to be downgraded on the next event).

You could also have the "waiting for busy" thread prod the actualy
working thread to quit early so it can start processing sooner.

The more threads you have, the bigger a performance dump you can
handle.

One more:
You can think of the event as having 2 functions:
1) start processing new data.
2) stop processing the old data, you are out of time, go back to 1.

	while( ! terminated )
	{	WaitForSingleObject( hevent, INFINITE );
nextevent:
		if( terminated )	break;

		ResetEvent();

		processlevel_1();
		if( is_signaled( hevent ) )
		{	final();
			goto nextevent;
		};
		processlevel_2();
		if( is_signaled( hevent ) )
		{	final();
			goto nextevent;
		};
		{ . . . . .}
		processlevel_N();
		final();
	};