[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Seamless restarts

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]

> Kurt D. Zeilenga writes:
> >At 03:14 PM 2002-11-25, Howard Chu wrote:
> >>Maybe I was getting confused with the surrogate parent stuff.
> >
> > Note that if you doing any fork() after any thread call
> > (direct or indirect), then you need a surrogate parent.
>
> Oh dear.
> Still, the shell backend seems to work anyway.
> The Solaris fork() manpage says:
>      If a Solaris threads application calls fork1()  or  a  POSIX
>      threads  application  calls  fork(), and the child does more
>      than simply call exec(), there is a possibility of  deadlock
>      occurring   in   the  child.
> OSF Alpha says something similar:
>      the child process should only execute operations it knows will
>      not cause deadlock until one of the exec functions is called.
> I can't find anything about threads vs. fork() in the Linux manpage.

This reminds me, I had to patch back-shell for OS/390. The OS/390 runtime
library fails fork() in a threaded program. I had to replace all of that with
the 390-specific spawn() function.

So what operations can cause a deadlock on Solaris and OSF?

I'm sure we already agreed on this - it would be safe to unconditionally
fork() a surrogate parent at slapd startup. The question then is, will the C
library spawn any threads behind our back, while we're resolving DNS names
and creating listener sockets? Certainly it could, depending on what the
resolver and/or NSS are doing. Again, to avoid the issue of descriptor
passing, the surrogate needs to be fork'd after the listeners are setup.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support