Subject: RE: NetBSD is not Linux
To: 'Chris Gilbert' <>
From: Stephane St Hilaire <>
List: netbsd-users
Date: 06/12/2001 12:19:39
>-----Original Message-----
>[]On Behalf Of Chris Gilbert
>Sent: Monday, June 11, 2001 7:35 PM
>To: ali (Anders Lindgren); ''
>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, 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
very complex.

>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.