-- Douglas F. Elznic delznic@acm.org "If they give you lined paper, write the other way." Freedom through Electronic Resistance ---------- Forwarded message ---------- Date: Sat, 10 Jan 1998 19:01:18 -0500 (EST) From: Christopher Blizzard <blizzard@appliedtheory.com> Reply-To: redhat-devel-list@redhat.com To: redhat-devel-list@redhat.com Cc: linux-kernel@vger.rutgers.edu Subject: Re: RedHat 5.0 and threads Resent-Date: 11 Jan 1998 00:01:20 -0000 Resent-From: redhat-devel-list@redhat.com Resent-cc: recipient list not shown: ;On Sat, 10 Jan 1998, H. Peter Anvin wrote:
:> :> Huh? Aside from the issues of portability why not use it? You don't have :> to worry about allocating a buffer for gethostbyname_r() and worry about :> it being big enough, etc... If gethostbyname() works, run with it! :) :> : :At least some of us think that portability is a big deal... :
Please excuse the rant that's about to happen...threads on Linux happen to be my sore spot. :)
<rant mode=on>
Actually, I happen to think that portability _is_ a big deal since what I do for a living is write multithreaded programs that have to run on Solaris, Digital Unix and even NT from the same source tree. This is why I get on so many Linux people's back about the state of MT under Linux. Most "big" unixish applications ( ie Oracle, Netscape's web servers ) are multi-threaded, through-and-through and really benifit from it.
There are a lot of applications and tools that my company writes that I would love to port over to Linux but when I have problems, I'm toast. gdb can attach to one thread at a time. This gets to be kind of tedious when you have a dozen threads running. Also, any post-mortem debugging is apparently impossible. Because of this it isn't exactly the most appealing applications development platform. There are a couple of patches floating around that help with these problems but they should really be applied to the kernel as a whole. If you want to distribute software and support it you don't want to tell your customer that they have to patch their kernel to help you fix your application.
People say that to make Linux a general success, it needs applications. Well, this is one huge area where Linux is really behind the big boys. glibc is a really big step towards making this happen, but I don't see the kernel people tuned to this problem which is where a lot of things need to happen. CLONE_PID isn't there and I can't imagine what has to happen to make that a reality. Then there's integrating pthreads to use it. I've seen some off-handed comments from a couple of people but no solid statements like "This will be available in 2.2 or 2.4". Also, there's the changes to gdb that have to happen as well.
If people want applications to run on Linux, then they have to make an exnvironment that application programmers will want to work in, even love to work in. Right now, if you want to do threads, you're basically up the creek. They are very usable, but there are some pretty big holes.
If I had the skills, I would make the time and do it myself. I'm not just saying that. Unfortunately, I don't. I can just sit on the sidelines and boo and whine about it. :)
I absolutely love Linux and hate to see applications people discount it because of this one problem. I've seen it happen.
</rant>
--Chris
------------ Christopher Blizzard AppliedTheory Communications, Inc. http://odin.appliedtheory.com/ blizzard@appliedtheory.com ------------
-- To unsubscribe: mail -s unsubscribe redhat-devel-list-request@redhat.com < /dev/null