Re: Thread deficiencies
Date: Mon, 3 Jan 2000 21:47:28 +0000 (GMT)
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
1. pthreads says that all threads share the uid/gid stuff.
To support this requires a setuid() in one thread changes the
security credentials of another thread on the fly _during_ a
syscall. Right now we have no locking on uid/gid paths and those
variables are very much critical performance points.
That one isn't that hard. Setuid() calls aren't all that common, so
simply making setuid() take the global kernel lock if the credentials
structure (we would need to move the uid/gid/group information to a
creds structure) is shared, probably isn't that unreasonable.
(I.e., if a process does a clone(CLONE_CREDS), then set the a
creds_cloned flag in the process, which is cleared if the process does a
subsequent exec. The other process might have the creds_cloned flag set
when it doesn't need it, but all that will do is cause an unneeded big
kernel lock when it calls setuid, which is probably acceptable.)
We have real people writing real applications and consistently
finding pthreads as designed is unusable. Pthreads needs to work, but
since its already a performance disaster it shouldnt be allowed to
intrude on sensible applications using efficient interfaces. Just
like with hardware - Linux has to make the fast stuff go very fast
and not cripple the fast stuff for broken stuff.
True, but if our pthreads implementation is far more inefficient than
the pthreads implementation of other Unices, Linux isn't going to look
all that good to application writers. We have to balance that against
not screwing up the efficiency of the "better" interfaces, and keeping
the kernel implementation relatively clean, but I think we can do better
than what we have right now.
I suspect part of the problem is that most of the kernel developers have
a very different sense of the importance/priority of getting this
address than most of the applications developers.
- Ted
Reply to: