>-----Original Message-----
>From: netbsd-users-owner@netbsd.org
>[mailto:netbsd-users-owner@netbsd.org]On Behalf Of Chris Gilbert
>Sent: Monday, June 11, 2001 7:35 PM
>To: ali (Anders Lindgren); 'netbsd-users@netbsd.org'
>Subject: Re: NetBSD is not Linux


>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


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

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

Steph