On May 22, 2007, at 12:28 AM, Eric Blossom wrote:
The priority is set to the midpoint of the FIFO range, not maximized.
My bad on the "maximized" ... but ... ummm ... no, not the midpoint either the way it's written, if I understand the function calls correctly. Here's the line:
int pri = (sched_get_priority_max (policy) - sched_get_priority_min (policy)) / 2;
The midpoint would be (... + ...) / 2. ;)
I don't think we want to be creating new threads just to try to set real time scheduling.
These changes are made to the current running thread, not to a new thread, just like the code in "gr_realtime.cc". IMHO GNU Radio already has enough threads, especially on OSX's implementation because of Apple's weirdness of requiring separate threads for callbacks on Audio and USB.
I strongly suspect that if a pthread implementation supports pthread_attr_setschedpolicy with SCHED_RR or SCHED_FIFO, then they will also implement sched_setscheduler with SCHED_RR or SCHED_FIFO.
On OSX 10.4.9 (and, I would presume any 10.4.X): sched_get_priority_max(), sched_get_priority_min (), SCHED_FIFO, and "struct sched_param" [and "struct sched_param".sched_priority] are defined in standard header files in /usr/include and seem to work as required for modifying the scheduling priority and policy. Strangely, the only part that's missing from headers is sched_setscheduler() ... which gets divided and renamed to pthread_attr_setschedpolicy() and pthread_attr_setschedparam().
I've tested out these pthread calls, and they work quite nicely w/o needs for su or root execution. Shouldn't be difficult to create an "#elif" condition in gr_realtime.cc for those with pthreads ... but first the config m4 script for pthreads needs to work (at least on OSX): config.h has "/* #undef HAVE_PTHREAD */" ... I will look into these. - MLD
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
