Subject: Re: NetBSD is not Linux
To: ali \(Anders Lindgren\) <firstname.lastname@example.org>
From: Chris Gilbert <email@example.com>
Date: 06/12/2001 00:35:19
On Tuesday 12 June 2001 12:20 am, ali \(Anders Lindgren\) wrote:
> On Mon, 11 Jun 2001 firstname.lastname@example.org wrote:
> > > >> You can of course create more than one.
> > > >
> > > >and each thread creates new process.
> > >
> > > Perhaps but they all share the same memory space (no IPC required for
> > > trivial tasks)so what's the problem exactly ?
> > that you can't have more than 4090 processes in linux. and other that
> > linux handles lots of processes terribly slow.
> This is kind of an interesting issue. People often put forward that Linux
> "kernel threads" suck because "one process/thread is known to be an
> inefficient way of implementing kernel threads", but I haven't really
> heard any arguments as to why it necessarily has to be? Why would it
> be inherently more inefficient than LWPs, which is just another layer
> put in between the unix proc structs and the scheduler (in SUNs
> implementation anyway) anyway?
I believe (rightly or wrongly) that using 1 proc per thread means that linux
threads will never be 100% posix compliant as signal handling doesn't work to
posix. In linux you sends a signal to a process, when it's a thread, the
thread gets the signal, not the overall threaded process, so the thread has
to handle the signal. Under LWP's the signal goes to the process and into
the process's signal handlers, rather than into a thread. What this means is
you can spawn a thread that just handles all signals sent to a process, under
linux you can't do this, and have to attach signal handlers to all threads as
you don't know which will get the signal.
I know it sounds like a small thing, but it means that the threading is not
posix compliant. But a lot of commericial unix apps are written using posix
threads, and not having that compatibility requires extra work (and
potentially complex work).
Another possible effect (but I'll happily be proved wrong) is that a thread
being a process may mean a full context switch is needed to go between
threads, I'd expect that LWP's may not need this?
> I am quite willing to believe Linux has a lousy implementation of threads,
> but the certainty with which the above quote is often put forward reminds
> me I'd like to know why this is "necessarily so".
I believe that's not so much lousy as different.