Messages in this thread | | | Subject | Re: [PATCH] [request for inclusion] Realtime LSM | Date | Tue, 11 Jan 2005 21:13:44 -0500 | From | Paul Davis <> |
| |
>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.
>developers. Simply add a library function to libjack or whatever: > > jack_make_me_important(...); /* pretty please */
like:
int jack_set_client_capabilities (jack_engine_t *engine, jack_client_id_t id);
along with various other things that will ultimately get the client to call functions like:
int jack_drop_real_time_scheduling (pthread_t thread); int jack_acquire_real_time_scheduling (pthread_t thread, int priority);
these functions are exported to clients, because some clients have other threads that require RT scheduling.
>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.
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?
--p - 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/
| |