[Date Prev][Date Next]
RE: Seamless restarts
> -----Original Message-----
> From: Hallvard B Furuseth [mailto:email@example.com]
> 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
Symas: Premier OpenSource Development and Support