[PD] [PD-announce] Pd 0.41 test 10 released

[Miller Puckette]

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~~~
>