RE: signal() behavior

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

I forgot to attach the diffs before. You can ignore the references to
SIGACTION, I don't see any reason to change things there if they don't
actually solve the problem.

--- daemon.c    1999/08/24 23:09:38     1.1.1.2
+++ daemon.c    1999/08/25 00:22:18
@@ -371,6 +371,8 @@
 static int sockinit(void);
 static int sockdestroy(void);

+static int selexit[2];
+
 int slapd_daemon_init(char *urls, int port, int tls_port )
 {
        int i, rc;
@@ -401,6 +403,8 @@
        }
 #endif /* !FD_SETSIZE */

+       pipe(selexit);
+
        FD_ZERO( &slap_daemon.sd_readers );
        FD_ZERO( &slap_daemon.sd_writers );

@@ -548,6 +552,7 @@
                memcpy( &writefds, &slap_daemon.sd_writers,
sizeof(fd_set) );
 #endif

+               FD_SET( selexit[0], &readfds );
                for ( l = 0; slap_listeners[l] != NULL; l++ ) {
                        if ( slap_listeners[l]->sl_sd == AC_SOCKET_INVALID )
                                continue;
@@ -1073,13 +1078,18 @@
                }
        }
 #endif
+       close(selexit[1]);
+#ifndef HAVE_SIGACTION
        /* reinstall self */
        (void) SIGNAL( sig, slap_set_shutdown );
+#endif
 }

 void
 slap_do_nothing( int sig )
 {
+#ifndef HAVE_SIGACTION
        /* reinstall self */
        (void) SIGNAL( sig, slap_do_nothing );
+#endif
 }
> 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
> >
>
>