[Date Prev][Date Next]
RE: signal() behavior
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.