Ingo Molnar <[EMAIL PROTECTED]> writes: > * Jack O'Quin <[EMAIL PROTECTED]> wrote: > >> In the absence of any documentation, I'm guessing about storing the >> nice value in the priority field of the sched_param struct. But, I >> have not been able to figure out how to make that work. > > the call you need is: > > setpriority(PRIO_PROCESS, tid, -20); > > where 'tid' is the TID (pid) of the thread in question. There's no way i > know of to utilize the pthread_t ID to do this, so you'll have to figure > the TID out via gettid() - which needs to happen in the child context - > how hard would it be to attach the TID field to some per-thread Jack > structure? [while the purpose is still a quick hack.]
Adding a tid field is relatively easy. Fixing the race condition between setting it in the new thread and using it in the creating thread is harder, but not impossible. But, even setting it in the new thread would create an incompatible interface. With hundreds of JACK client applications, binary compatibility is a serious consideration. Due to the absurd difficulty of successfully creating a realtime thread under the various incompatible Linux kernels and pthread libraries, we export jack_create_thread() to applications. That way, they can take advantage of our latest fix for the latest NPTL botch (0.60 was particularly bad). So, the new thread's start_routine is not necessarily ours. I suppose we could provide an internal function to intialize the thread and then call the requester's start_routine. But, this is getting to be a significant time sink. Eventually, I can probably cobble something together that will establish whether your current 2.6.10 SCHED_OTHER works with nice -20. Is that all we're trying to accomplish? I do think it can be made to work (on some kernel versions, given appropriate privileges, with kernel thread priorities adjusted properly, etc.). But, that does not meet any of my needs. -- joq - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
