Re: signal() behavior

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Howard Chu wrote:
>The solution seems to be to check for sigaction() in configure, and use it
>instead of signal() if it's found. I'll make this fix in a little while.

Though I think moving to sigaction is a good idea, I don't think
such a move will help.  LinuxThreads signal handling is broken.
That is, LinuxThreads does not provide the signal behavior prescribed
by the Pthread specification.

Mark Valence wrote:
>There has to be some way to make this work "correctly" on all 
>systems, and that's what I've been searching for.

Use of signal(2) is definitely not very portable, especially
when used in conjunction with threads.  This is namely due to
poor implementation of the Pthread standard.   Also, select(2) is
problematic when used in conjunction with threads.  This is
largely due to fact that select(2) behavior is not defined
by the threading specifications.

(see archives for prior discussions on this)

I agree we need something better... I'm not sure exactly what that is.
I've been looking into using BINDv8 event library or similiar
services.  Discussions in this area are quite welcomed.

Kurt