Well, if in callback mode, the non-interrupt main loop is also in a different thread from the audio (if I understand correctly) and so there shouldn't be any difference between adding stuff to Pd's "main" thread and adding other threads. I think the locking considerations are the same too.
So it's probably adequate just to have the callback scheduler obtain the "global lock" and let externs add whatever they want as separate threads. Come to think of it, that also would remove the need for an idle() function in case one is using the polling scheduler too, no?
cheers Miller
On Fri, Dec 28, 2007 at 08:47:26PM +0100, Thomas Grill wrote:
Am 28.12.2007 um 20:25 schrieb Miller Puckette:
I should have put the lock in and forgot... thanks for the reminder.
I'm not at all sure how to handle "idle" in the callback case. One could just call the function forever, but that seems like burning the CPU for nothing.
You might have noticed that the idle callback function in pd-devel
returns 0 (when it never wants to be called again), 1 (when it wants
to be called again as soon as possible) or 2 (when it wants to be
called again at the next scheduler iteration). This works pretty well
and helps to preserve cpu.Alternatively, "idle" processing might want to take place in a different thread to be set up by whatever external code wants to do the idle processing, trusting to the OS to preempt to the callback thread when it becomes runnable.
It's a cleaner approach given the fact that the functionality allowed
within the audio driver callback is limited, but it involves locking
which isn't nice.gr~~~