RE: signal() behavior

["Howard Chu" <hyc@highlandsun.com>]

Thanks for the response, Mark. With that hint, I have a working kludge.
In daemon_init, open a pipe that is never used for anything, but include it
in the set of readfds. In the signal handler, close the write side of the
pipe - select will return at that point.

> -----Original Message-----
> From: owner-openldap-devel@OpenLDAP.org
> [mailto:owner-openldap-devel@OpenLDAP.org]On Behalf Of Kurt D. Zeilenga
> Sent: Tuesday, August 24, 1999 5:05 PM
> To: Mark Valence
> Cc: openldap-devel@OpenLDAP.org; Howard Chu
> Subject: Re: signal() behavior
>
>
> 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
>