Re: Thread deficiencies
> No question that POSIX.4 is heap of stinking shit. The problem is that
> it's a *standardized* heap of stinking shit, and application writers
> want to be able to cleanly port their programs from other Unices to
> Linux.
No argument. And thats why we should support it, and yes the libraries will
have to do a chunk of gunge work to emulate the flaws in it.
> Independent Software Vendors, so sorry, unlike every other Unix system
> on the planet, you have to use clone() and not the standardized POSIX
> interfaces. Now go away and stop bothering us? The problem is, they
> may do exactly that.
We need to standardise clone(). We don't need to standardise on clone() but
not posix.4. Standardising clone "temporarily" as the IBM guy suggests is
not sane. Clone is a real working API. If you want to use clone its there
it works. If you want to use pthreads then clone is a piece of specification
you don't care about. Removing it in future is the error.
> Do we say that we "almost but not quite" implement POSIX.4, and then
> list all of the ways that we don't quite match the spec? That won't
> make us a lot of friends in the application developer world (who will
> ask why can't we support all of POSIX.4), but it's at least honest.
For the existing LSB I think we should document the subset we support.
A 'future directions' statement is probably appropriate but I guess thats
one to ask Ulrich about.
> what are the minimal kernel hooks necessary so that libpthreads can do
> something more like what POSIX.4 compliant applications expect. hpa has
I had a look. They are absolutely unspeakably foul. Believe me we get a lot
of people saying "Why does it..." and a lot of folks wanting to find fixes
A couple of starter problems
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.
Locking all over the kernel for that is silly
2. pthreads says signals get distributed to all or for some cases
randomly
If we distributed queued signals around threads then the per thread
queues are time ordered, but the time order between events that hit
different queues has been destroyed
Think about
SIGIO fd 4, data ready
SIGIO fd 4, close
other queue
SIGIO fd 4, open
SIGIO fd 4, open
SIGIO fd 4, close
What happened, which connection got the data. The poor pthreads design
has blasted this information into oblivion.
The best I can come up with on this is that we leave the setuid mess to the
pthreads library because it rarely occurs so it isnt a performance issue and
can be done by inter-thread message mess.
The signal stuff does seem to need a little kernel help, but it has to default
to sanity not posix.4, and the delivery paths are extremely performance
critical.
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.
Alan
Reply to: