> yodaiken@chelm.cs.nmt.edu writes:
> > On Thu, Jul 15, 1999 at 06:00:33PM -0600, Larry McVoy wrote:
> > > Why? I can construct the same behavior in LinuxThreads using interfaces
> > > that have been here for 20 years or more. The only thing that is not
> > > true about that statementis that I have to be deterministic about which
> > > thread gets the signal, and the POSIX standard lets the system pick one
> > > at random. Personally, I'd prefer to be deterministic. It makes debugging
> > > a hell of a lot easier.
> >
> > signal_handler:
> > catch signal
> > use whatever nutty algorithm is wanted to pick a thread
> > toss in time, random numbers, stock valuations,
> > pthread_kill(selected_thread, ...)
>
> I'd like to know why LinuxThreads never did this. Is there some
> subtlety that we're missing? It would be nice if it could be done like
> this.
Well, if I'm reading it right it is probably because pthread_kill cannot
be made async signal safe..
It seems to me that signal handling in the current linux model is the
biggest detriment. In the posix model it is pretty direct, you block off
all the signals you want to deal with in all threads and then dedicate
a thread to handling the signal using sigwait.
In the linux model a signal targetted at a single process will not be
handled by this mechanism. Since none of the syncronization primiatives
are async signal safe that leaves no way to deal with signals.
At least this is what I found last year when I was hoping to catch
sigwinch in a multithreaded program.
As an aside, does core dumping work with the current model? Does a SIGSEGV
terminate all the processes and create a dump file that contains state
information for them all?
Thanks,
Jason
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/