This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: linuxthreads question


> The problem is that this is really a situation which is not (yet)
> supported.  No user beside root so far can change the priority of the
> threads but this is no general problem, it's because we still have no
> complete capability implementation.  The kernel returns an error code
> which says EPERM but this error message really means that "changing
> priorities is not supported for normal users".  It's not supported
> since the detailed methods to control this are missing.  It does not
> fail because there is a general permission problem and normal users
> are never allowed to do this.

The same can be said of `mount' and dozens of other cases.  The point is
that it *is* a permission failure by definition, because if that process
could do seteuid(0) then the call would succeed.  Using EPERM would be
consistent with other cases where one must be root for whatever reason.

The fact that there is any circumstance under which the call might succeed
with those parameters means that ENOTSUP is inappropriate.  It is clearly
against the spirit of the standard to use ENOTSUP for a feature that is in
fact available to some processes on the system at some times.

> Anyhow, I don't think pthread_attr_setschedpolicy should provide this
> error code.  

The issue to me is not so much how it diagnoses that kind of failure (or if
it does at all, which it is not required to do), but that it badly misuses
ENOTSUP, whose purpose is otherwise unambiguous and clear.

> But fixing the pthread_create code is really hard.

That is another issue.  


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]