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@apple.com>
Date: July 12, 2005 10:57:16 PM EDT
To: james tittle <tigital@mac.com>
Cc: unix-porting@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