Hi, the implementation of setpriority is broken, as it doesn't allow the super user to lower the priority of the task *and all threads it contains* below the current minimal priority of the threads/processor set (I am liberally mixing POSIX priorities with Mach concepts here). Also, it reports the tasks priority, but this is not the acutal or enforced priority (for example, a normal user can lower the priority of a task to -10, but willg et an error, and indeed the threads won't have the desired priority).
This needs more work. Of course, we only need to give a consistent view in the POSIX world if the user doesn't use Mach calls directly. I suggest that if task_priority fails, it is called again with the old priority to make the getpriority report the correct value. If the user is the superuser, he can request the processor set ports and use that to set the threads max (for POSIX: min) priority. All this ignores the max priority of processor sets, this is something I haven't checked yet. It seems to me we should set the processor sets max priority to the highest value by default. Actually, I haven't really spent too much thought on this, maybe someone can investigate the remaining details and develop patches for glibc (and maybe proc, which would set the processor sets priorities, I think). If the Mach picture is not good enough, we might save the priority of a task/thread in proc. From a first glance, I don't think that it is needed. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
