[PD-dev] Fwd: sched_setscheduler(), posix and 10.4.x?

[james tittle]

hey tim,

...as you can see, I posted to a "unix-porting" list at apple, and  
got this neat-o response:  so whatcha think?  Not as portable as once  
thought, I'd imagine...I'd guess it also wouldn't work on other  
bsd's, but then, is anyone running pd on a *bsd?

...back to the drawing board for me...

l8r,
jamie

Begin forwarded message:

> From: Terry Lambert <tlambert at apple.com>
> Date: July 12, 2005 10:57:16 PM EDT
> To: james tittle <tigital at mac.com>
> Cc: unix-porting at lists.apple.com
> Subject: Re: sched_setscheduler(), posix and 10.4.x?
>
>
> On Jul 12, 2005, at 5:47 PM, james tittle wrote:
>
>> hi,
>>
>> ...I'm working on a crossplatform app in which someone has  
>> implemented sched_setscheduler(), and apparently it's not  
>> available on 10.4.x?  I've tried compiling against the 10.4.0.sdk  
>> using:
>>
>> gcc -framework CoreAudio -framework AudioUnit -framework  
>> AudioToolbox -framework Carbon -framework CoreMIDI -isysroot / 
>> Developer/SDKs/MacOSX10.4.0.sdk -Wl,-syslibroot,/Developer/SDKs/ 
>> MacOSX10.4.0.sdk -O3 -fprefetch-loop-arrays -faltivec -maltivec - 
>> isysroot /Developer/SDKs/MacOSX10.4.0.sdk (...snipped lotsa  
>> filenames...)
>>
>> ...but still no luck...this seems to violate the POSIX standard,  
>> because unistd.h does define _POSIX_PRIORITY_SCHEDULING, whereas  
>> "POSIX systems on which sched_setscheduler and sched_getscheduler  
>> are available define _POSIX_PRIORITY_SCHEDULING in <unistd.h>."
>>
>> help?
>>
>
> The code you're trying to compile is not technically portable; the  
> value (-1) means "unsupported" according to the current POSIX  
> standards document.  You will tend to have problems porting it to  
> other POSIX or POSIX-like platforms, not just MacOS X.
>
> This is an increasingly common mistake that pops up now due to a  
> change between POSIX  1003.1-2001 and POSIX 1003.1-2003, which  
> requires that these values be defined in all cases, but have  
> particular values based on whether or not the option is supported  
> (-1 means "unsupported"; 0 also means "unsupported", and is  
> included because if the value is not #defined at all, and you do  
> math with it, the ISO c99 standard requires a preprocess treat the  
> value as if it were zero; 200112L means "supported").
>
> That means that the feature test in C programs has to change from:
>
>     #ifdef _POSIX_PRIORITY_SCHEDULING
>
> to:
>
>     #if (_POSIX_PRIORITY_SCHEDULING - 0) >=  200112L
>
> Which is what it really should have been all along.  Technically,  
> it could also be:
>
>     #if defined(_POSIX_PRIORITY_SCHEDULING) &&  
> (_POSIX_PRIORITY_SCHEDULING == 200112L)
>
> But if you used that variant, your code would not be future-proof  
> against newer versions of the standard bumping the constant from  
> 200112L to something larger (obviously, they could also change the  
> semantics if they did that, but you at least have a fighting chance  
> of your code still working without additional changes).
>
> See also:
>
>     http://www.opengroup.org/onlinepubs/009695399/basedefs/ 
> unistd.h.html
>
>
>      "If a symbolic constant is defined with the value -1, the  
> option is
>       not supported. Headers, data types, and function interfaces  
> required
>       only for the option need not be supplied. An application that  
> attempts
>       to use anything associated only with the option is considered  
> to be
>       requiring an extension."
>
>      [ ... ]
>
>      "_POSIX_PRIORITY_SCHEDULING The implementation supports the  
> Process
>       Scheduling option.  If this symbol is defined in <unistd.h>,  
> it shall
>       be defined to be -1, 0, or 200112L. The value of this symbol  
> reported
>       by sysconf() shall either be -1 or 200112L."
>
> Hope that clears things up for you!
>
> -- Terry
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050712/6d0f9bd8/attachment.htm>