Messages in this thread | | | Date | Wed, 12 Jan 2005 11:09:49 -0800 | From | Matt Mackall <> | Subject | Re: [PATCH] [request for inclusion] Realtime LSM |
| |
On Tue, Jan 11, 2005 at 09:13:44PM -0500, Paul Davis wrote: > >And that is a failure of imagination on the part of the JACK > > Please be careful with your words. Based on your comments below, it > appears that you've never read any of the technical docs on it, and > almost certainly never read the source code.
I thought I made it clear that I didn't even know the name of library. And I thought I understood from you that you had to do different start-up per client depending on whether RT was available. Have I misunderstood you?
> >A client starts at normal priority, asks jack nicely to promote it to > >RT, then jackd, if so configured/enabled, calls the wrapper with a PID > > a PID? clients are multithreaded, and only specific threads run with > RT scheduling (normally just the one created for them by > libjack). So you presumably mean a TID, which in turn creates a > problem for any system (e.g. 2.4) where all threads share the PID, and > sched_setscheduler() really does use the PID as a PID, not a TID.
That actually sounds like an independent API problem.
> but its gets worse. JACK clients need to drop RT scheduling under > certain, well-defined circumstances. how do they get it back under > this scheme?
Assuming a more thread-aware API, they just ask for privileges again. But with the non-thread-aware API, my first reaction would be the thread in question clones, and the clone drops privileges.
-- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |