[PD] -rt for whom?

Miller Puckette mpuckett at man104-1.ucsd.edu
Tue Jul 6 00:07:15 CEST 2004

Until recently (0.37 I think) Pd just tried to renice itself on OSX, but
currently it uses pthread_setschedparam() to set the SCHED_RR policy.
I'm not sure how this relates to SCHED_FIFO and I sure should find out :).

Pd effectively tries to make its main thread the "real-time" one.  If
you stick hard-core computations in the main thread, as GEM does, this
can have a bad effect on your machine.  THis is why "-rt" and GEM
disagree with each other on OSX - and I suppose on linux as well although
I don't know that.


On Mon, Jul 05, 2004 at 04:57:47PM -0500, chris clepper wrote:
> On Jul 5, 2004, at 3:24 PM, Larry Troxler wrote:
> >On Monday 05 July 2004 13:57, chris clepper wrote:
> >>A few notes about -rt mode:
> >>
> >>First, -rt is different on OSX compared to Linux.  On Linux, the flag
> >>sets the priority of the pd process just like nice or renice
> >
> >Sorry if I somehow have a basic misunderstanding about how POSIX  
> >real-time
> >scheduling works on Linux,  but I think  you're very wrong (or else the
> >behavior of "nice" has changed a bit since the last time I researched  
> >it).
> I think you completely missed the point I was making, which concerns  
> the difference between the way processes are represented in the two  
> systems.  You may indeed be right that (re)nice won't do exactly the  
> same thing as calling the POSIX scheduling API, but the point is that  
> treating scheduling on OSX just like Linux is worthless because the  
> kernel looks at tasks and threads differently.  More to the point, Pd  
> has no actual real-time scheduling enabled on OSX, so the -rt flag is a  
> misnomer to begin with.  Real-time scheduling would be done using the  
> Mach kernel thread API as outlined in this document:
> http://developer.apple.com/documentation/Darwin/Conceptual/ 
> KernelProgramming/scheduler/chapter_8_section_4.html
> The section under 'Using the Mach Thread API to Influence Scheduling'  
> contains the relevant info.  Setting priority to FIFO doesn't appear to  
> do anything at all related to 'real-time' scheduling.  By 'real-time' I  
> mean that exact amounts of time in cycles are set aside for a given  
> process per second and having the kernel agree to only do that task in  
> those cycles.  Just setting a high priority for a thread won't do that,  
> and also has some nasty side-effects as evidenced by GEM.  Again, this  
> is apparently completely and totally different from Linux 'real-time',  
> and implementations should reflect that.
> _______________________________________________
> PD-list mailing list
> PD-list at iem.at
> to manage your subscription (including un-subscription) see
> http://iem.at/cgi-bin/mailman/listinfo/pd-list

More information about the Pd-list mailing list