(*** This bug was imported into bugs.kde.org ***) The test for whether setting realtime priority (on systems with with POSIX realtime scheduling support) worked seems to be wrong. The return value of sched_setscheduler() is being checked for "==0" means success but the sched_setscheduler(3RT) man page (at least on this system "SunOS garland 5.8 Generic_108528-13 sun4u sparc SUNWUltra-5_10") says: RETURN VALUES Upon successful completion the function returns the former scheduling policy of the specified process. If the sched_setscheduler() function fails to complete successfully the policy and scheduling paramenters remain unchanged and the function returns -1 and sets errno to indicate the error. So the check for success should be "!=-1". Here's a patch for that and also to report why if the call fails (useful for debugging): --------------------------------------------------------------------- --- arts/soundserver/artswrapper.c.origThu Jun 20 10:41:31 2002 +++ arts/soundserver/artswrapper.cThu Jun 20 11:44:04 2002 @@ -174 +175 @@ #ifdef HAVE_REALTIME_SCHED #include <sched.h> +#include <errno.h> void adjust_priority() @@ -345 +355 @@ sp.sched_priority = priority; -if(sched_setscheduler(0 SCHED_FIFO &sp) == 0) +if(sched_setscheduler(0 SCHED_FIFO &sp) != -1) { printf(">> running as realtime process now (priority %ld)\n" @@ -434 +445 @@ { /* can't set realtime priority */ +printf(">> cannot set realtime scheduler %s\n"strerror(errno)); putenv("STARTED_THROUGH_ARTSWRAPPER=2"); } --------------------------------------------------------------------- -- Jonathan Marten SCM Team Engineer VSP Bracknell UK jonathan.marten@uk.sun.com Sun Microsystems "Progress is not expedited by frequent requests for progress reports"
As the line still says ==0, is this still not working for you?
Still fails in KDE3.1 (with the "==0"), with the same message. However, the daemon appears to start correctly as a realtime process: UID PID PPID CLS PRI STIME TTY TIME CMD jonm 23597 2493 RT 129 14:07:19 ? 0:01 /usr/local/kde/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -l 2 -f so the problem is just reporting a suprious error. Applying to the original patch to artswrapper.c from KDE3.1 again starts artsd as a realtime process (as above), but with no error message. So it looks as if this fix is still needed.
With KDE 3.1.2 I am seeing artswrapper cause artsd to print: Can't set real-time scheduling priority. You need to run artswrapper as root or setuid root. This means that you will likely not be able to produce acceptable sound (i.e. without clicks and breaks). I can also confirm that the man pages described above are correct and that the above patch works in Solaris. Without this I am not seeing artsd running as realtime.
*** Bug 60338 has been marked as a duplicate of this bug. ***
Subject: arts/soundserver CVS commit by akrille: Changed the if(...) line. Nonetheless arts complains at startup (and only on startup) altough it runs with realtime-priority. Even artscontrol says all is well. strange... CCMAIL: 44150@bugs.kde.org M +1 -1 artswrapper.c 1.15 --- arts/soundserver/artswrapper.c #1.14:1.15 @@ -34,5 +34,5 @@ void adjust_priority() sp.sched_priority = priority; - if(sched_setscheduler(0, SCHED_FIFO, &sp) == 0) + if(sched_setscheduler(0, SCHED_FIFO, &sp) == -1) { printf(">> running as realtime process now (priority %ld)\n",
Subject: Re: arts/soundserver You now check for "== -1" but the bugreport suggested to check for "!= -1". I don't think your change is correct. Cheers, Waldo On Wednesday 25 June 2003 13:55, Arnold Krille wrote: > CVS commit by akrille: > > Changed the if(...) line. > > Nonetheless arts complains at startup (and only on startup) altough it runs > with realtime-priority. Even artscontrol says all is well. strange...
Subject: Re: arts/soundserver On Wednesday 25 June 2003 14:07, Waldo Bastian wrote: > You now check for "== -1" but the bugreport suggested to check for "!= -1". > I don't think your change is correct. Sory, you are right. Could some confirm wether it is fixed now? Arnold
As george staikos even backported this fix to ARTS_1_1_BRANCH I think this can be closed.