Re: [nssldap] release 0.2 of nss-ldapd

[David Houlder <david.houlder [at] anu.edu.au>]

Arthur de Jong wrote:
...
> On Tue, 19 Jun 2007, David Houlder wrote:
...
> > (Having said that, I think the current signal handling could be fixed 
> > by blocking SIGPIPE with pthread_sigmask() and then "soaking up" any 
> > pending SIGPIPEs before return with sigwait())
>
> Any pointers to do this in a safe way? Also would compiling and linking 
> the NSS module with -pthread cause any extra overhead for non-threaded 
> applications?

Here's my idea. Not tested on any platform yet.

At the start you do...

assert(0==
  pthread_sigmask(SIG_BLOCK, &just_the_sigpipe_bit, &saved_mask));

At the end you do...

if (!(saved_mask & just_the_sigpipe_bit)) {
  /* soak up pending sigpipes before restoring mask */
  while (1) {
    pending_signals=0;
    while (sigpending(&pending_signals)==-1 && errno==EINTR) {}
    if ((pending_signals & just_the_sigpipe_bit )==0)
        break;
    sigwait(&just_the_sigpipe_bit, &junk_int);
  }
  assert(0==
    pthread_sigmask(SIG_SETMASK, &saved_mask, NULL));
}

It assumes that the SIGPIPE will always be delivered to the thread that 
causes it (which I think is true - 'thread dirceted' signal), and that 
SIGPIPE is synchronous (which it is, right?).

As for linking with -pthread, I see that the current libnss_ldap.so on 
Linux has weak symbols for __pthread_*, and doesn't actually link 
against libpthread.so. I'm guessing this might mean it uses some stub 
__pthread_* functions in a non-threaded application, and the real 
pthread lib in a threaded application. Just guessing though.

cheers
David.

--
David Houlder
david.houlder@anu.edu.au
http://davidhoulder.com