On Sun, 25.04.10 02:30, Maarten Lankhorst (m.b.lankhorst at gmail.com) wrote: > >What concerns me a bit here is that RT programs must be written in an > >RT specific style to make sense. That means they must internally know > >which threads to make RT and which ones not, and when. From the > >"outside" of the codebase that is difficult to control, especially since > >information about threads in processes is not really available from the > >outside on Linux (yes, you can find out about them, but you don't really > >know which one is which...). > > Well, the use case would be wine's wineserver. On windows programs > usually set audio threads to THREAD_PRIORITY_TIME_CRITICAL to > indicate that they have to have a certain priority. But in windows > thread handles are global, so doing it inside wine's 'ntdll' library > wouldn't make much sense, since the request to set the priority > would go to wineserver first, since there's no way to tell from > inside a wine program to tell which handle corresponds to the > thread, or even if that handle is local or not. Wineserver controls > this information so all requests that involve handles involve a > wineserver call, in general. So racing cannot happen, because > wineserver is the only one making the requests. OK, I think I underfstand. > If those applications would try to do bad things on windows xp you > could lock up the entire system, since it will not reset the > scheduler, even if that means on a single core system that it will > lock everything else out. ;) Well, Linux is not too much different there, unless rtkit enforces some policy on handing out RT. > >Also, RT programs must be RT from beginning of their RT code to the > >end. If you control their RT scheduling only from the outside this is > >almost definitely racy. If you want to control RT privs from outside of the > >process, then the only non-racy way would be to use inheriting across an > >exec(), which however is something rtkit explcitily prohibits. > >I am also wondering how many people would use this functionality instead > >of the lower level, chrt(1) command? > > Well, I'm aware rtkit is pulseaudio only, but there have been some > people who already use SCHED_RR with wine, mainly people who use it > for professional audio with jack or asio. This patch is not > officially part of wine, because of the possibility of abuse and > forkbombs. Out of tree patches are used. Oh, actually rtkit is not PA only. I do encourage use in other applications, and I know some already do. rtkit is supposed to be a way that user software can acquire RT priv safely and while being supervised, regardless if that user software is PA or something else. > What would prevent a process from using ptrace on another process > with the same uid, and then request realtime priorities from it? I > just want it somewhat easier, in a way that I can use it in wine. :) Well, my reluctance was not really based on security concerns. > >So, convince me! > > I'm not sure how this patch would encourage writing improper rt > code, since you could just use rtkit.c in your project for rt > already. This will just let wine benefit from the existing > functionality in a saner way. OK, I am convinced. ;-) And yes, your use of rktit certainly makes a lot of sense. Patch looks goot to me. But could you fix one thing: I think MakeThreadRealtimeWithPID() (or something like tht) would be a better name than MakeThreadRealtime2(). After examples like wait(), wait3() and wait4() in Linux, I cannot say I am a big fan of numbering function calls. ;-) Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
