Christopher Smith writes:
> On Tue, Mar 28, 2000 at 01:06:08AM -0700, Richard Gooch wrote:
> > You could probably write a native Linux threads library (lthread_*()
> > anyone?) which was just as easy to use and powerful, and didn't
> > require buggering the kernel. So from the point of view of the kernel
> > community, there is reluctance to throw complex and ugly
> > POSIX-specific support code into the kernel, for the sake of
> > compliance with an ill-considered standard. Leave the problems to
> > user-space, and hence the performance problems people mention.
>
> 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.
> 2) Support for high-speed synchronization structures. In particular,
> one should be able to do thread synchronization much more
> efficiently than processes synchronization.
We've got that already in libpthread, and it would be easy enough to
transport over to liblthread if you wanted.
> 3) Was integrated into the glibc library, so I didn't have to worry
> about reentrancy problems.
No technical problems there.
> This all seems highly unlikely to me, and this is why I really would
> like to have a good POSIX-threads implementation for Linux. Perhaps
> I'm wrong though. Can someone point me to an implementation of threads
> on Linux that comes close to the above criteria? If such a beast
> doesn't exist, it seems to me that there would be some advantages to
> considering the kernel support for POSIX threads option. These
> include:
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
- is there a solution to the pthreads/kernel problem that Linus will
accept
- what is the cost of such solutions to the kernel and what complexity
does it bring
- would an efficient lthread implementation provide an acceptable
alternative for those who care more about speed than portability?
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.
Even now, I still retain my hooks to the native interfaces, because
there are plenty of installed systems which don't have pthreads. Not
everyone will or can install the latest OS version from the vendor.
If we come up with something like Solaris Threads, which is almost
identical to pthreads, then you can hide the details in a bunch of
macros. Of course, lthreads would be more different, since we'd drop
the process/thread distinction, but for a lot of threaded
applications, *that doesn't matter*!
> There was a time when the mantra for Linux was, "when given a choice
> between following the standard and doing something cool, I followed
> the standard." Perhaps that time has passed, but I think it's worth
> reflecting on the merits of that argument and how helpful it's been
> for Linux to date.
>
> It appears to me that by NOT being POSIX compliant in this area, you
> limit the ability to leverage many of POSIXes other features in a
> threaded program in general. Furthermore, you require a LOT of
> reworking in userland libraries and such undoubtedly creating
> incompatibilities.
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.
Regards,
Richard....
Permanent: rgooch@atnf.csiro.au
Current: rgooch@ras.ucalgary.ca
-
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:23 EST