Subject: RE: NetBSD is not Linux
To: 'Chris Gilbert' <firstname.lastname@example.org>
From: Stephane St Hilaire <email@example.com>
Date: 06/12/2001 12:19:39
>[mailto:firstname.lastname@example.org]On Behalf Of Chris Gilbert
>Sent: Monday, June 11, 2001 7:35 PM
>To: ali (Anders Lindgren); 'email@example.com'
>Subject: Re: NetBSD is not Linux
>I believe (rightly or wrongly) that using 1 proc per thread means that
>threads will never be 100% posix compliant as signal handling doesn't work
>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
I'm not sure I understand the nuance, the moment your signal handler gets
called what does it matter which thread it runs from (hopefully it's the
thread that generated it) ? Depending on what you typically do in this
situation, the code should still work. Should the OS generate as many
signals as you have threads running ?
>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.
It's allways a thread that gets the signal, perhaps it normally would be
your main() thread but again this doesn't necessarly matter.
>What this means is
>you can spawn a thread that just handles all signals sent to a process,
>linux you can't do this, and have to attach signal handlers to all threads
>you don't know which will get the signal.
This would have to be tested but considering how Linux implemented threading
(some interesting stuff can be found at
http://linas.org/linux/threads-faq.html), there shouldn't be anything to
prevent the original thread to setup it's signal handlers prior to starting
additionnal threads and for all of these to get a copy of the signal table
(it's built in, whether or not the pthread calls use this facility is
another question, it would have to be tried out).
>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
>threads, and not having that compatibility requires extra work (and
>potentially complex work).
Registering signal handlers for each thread would be annoying yes but not
>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?
Well not really, the entire memory space doesn't have to be switched. I
haven't seen anything on the web about Linux thread switching being slower
than other implementations.