I think that clone() vs. LWPs and the like, as Linus said, is fine,
especially in the short run. Moreover, changing the kernel interface
seems like a step backward: we need a stable kernel interface so that
tools like a multithreaded debugger can be written for Linux. (Peeter
Joot has submitted some patches to 2.1.59 or so, that provide a /proc
interface for thread management. I haven't seen anything recently on
this--I wish it had higher priority.) This is going to be a big
headache, but it needs to be done.
Although I am not up to the minute on LinuxThreads, the last time I
checked in, the signal-delivery and other issues were still there.
I have been told by some ISVs (eg, Kubl, Software AG) that they have
Linux ports of multithreaded programs, but the lack of a multithreaded
debugger has made it harder to be confident in the ports. Kubl won't
release their code. Software AG's DCOM beta can deadlock, and they
don't have the time to debug it with "lots of printfs" (paraphrase from
Xavier Leroy's LinuxThreads FAQ.)
Cheers,
Matt Benjamin
Perry Harrington wrote:
------------------------------
From: Perry Harrington <pedward@sun4.apsoft.com>
Date: Tue, 10 Mar 1998 22:50:06 -0800 (PST)
Subject: Re: mmap() versus read()
> >
> > PPC Linux does this in the idle task -- a big win. So if the problem
is speed
> > of clone,then we should speed up clone.
----> SNIP <-----
Having a Solaris compatible libthread
interface would be another step to making Linux acceptable in the
"corporate"
world. Robust threading is a prime requirement for mission critical
programs
that would otherwise occupy a Sparc...
>
> I'm sure people can find threads that are even more light-weight than
> clone(), but I don't think they'll be as generic as clone(), and I
doubt
> they'll be _much_ faster.
----> More Snippage <----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu