-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Mar 28, 2000 at 03:33:00PM -0700, Richard Gooch wrote:
> Christopher Smith writes:
> > Hmm... it would be nice if there was a thread library that let me
> > have:
> >
> > 1) Solid support for signals, including real-time signals and such
> > interesting RT signal extensions that normally require
> > POSIX-threads. (Indeed, at least in the POSIX world queue'd signals
> > seem to be the way to go, and I'd hate to handle signals any other way
> > in a threaded world.)
> RT signals work fine with clone()ed processes.
so _POSIX_THREADS_PER_THREAD_SIGNALS_1 is effectively true?
Is there some way to do SIGEV_THREAD?
> Maybe the community should sit down and hammer out the following
> points, once and for all:
>
> - do we actually need efficient (POSIX compliant) pthreads for Linux
I think yes. Perhaps it doesn't have to be the most efficient
threading API on Linux, but it should be reasonably efficient. There
are lots of developers/companies who build their software specifically
to POSIX API's, and I think there is a value add to having their
software run reasonably well (and reliably) on Linux. A case in point
is the blackdown group, who didn't so much have problems with
performance, but they did find that pthreads behavior was different
enough from standard POSIX that we had to wait years before there was
a stable native-threads capable version of blackdown-java on Linux.
> - is there a solution to the pthreads/kernel problem that Linus will
> accept
It would be good to hear from some of the Pthreads guys on what
they've tried so far and what conclusions they've reached. It sounds
to me that Linus' requirements on what he'll except are eminently
reasonable (indeed, they seem like the only way to go). I have to
imagine there's a way to make this work.
> - would an efficient lthread implementation provide an acceptable
> alternative for those who care more about speed than portability?
I think so, so long as the pthreads solution is not prohibitively
slow. Keep in mind that a lot of people use POSIX threads to get
better performance than a process based model, so pthreads is only
useful to them if it's fairly efficient.
> On the last point, it's worth noting that every vendor has had their
> own threads API, and people have used it. In my own code, I've made
> use of IRIX's native sproc(2), Solaris Threads and Linux's
> clone(2). Sure, it's a bit ugly having all those #ifdefs, but it
> works, and my code is portable.
>
> What, I hear you ask. How is it portable? Simple: my applications use
> my wrapper layer. What matters to me is that I've had threaded
> applications for over 5 years. If I had to wait for vendors to
> implement and debug pthreads, I'd only now be shipping threaded
> applications.
While this is a good point, there are disadvantages to this approach,
particularly with something as close to the system level as
threads. Having a portable way of dealing with Linux's divergences
from POSIX threads signals behavior is a non-trivial task, and there's
nothing your threading library can do to convince external processes
that all your threads have the same PID. So, so long as your
application doesn't need these kinds of things (and a lot of them
don't), so long as you're willing to invest the effort to learn the
specifics of each platforms thread library, and so long as your
application can live with a least common denominator implementation of
threads, you're ok.
Having a working POSIX threads means that people don't have to
implement their own (and potentially inefficient and buggy) thread
abstraction layer. This saves application developer time. So, as long
as this doesn't cost us kernel developer time (which I guess would
require that we live in a perfect world rather than the real one ;-),
it's a good thing to have.
> We *are* following the standard. Or at least, pthreads in Linux is
> supposed to. It's just that the efficiency isn't that good. I see no
> reason we can't have both: pthreads for compliance, and lthreads for
> speed.
I agree, with the caveats mentioned above.
- --Chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.5 and Gnu Privacy Guard <http://www.gnupg.org/>
iD8DBQE44k7NfrrCpthD+UYRAsZVAKDeTfRgdZwQ+rjEROWQQThHJ18HoQCeJhJX
GLpE3RiNyfLpQyXXpjtmAtU=
=3Fgq
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:25 EST