Re: GSS-APIv3 sketch

[Nicolas Williams <[e-mail]>]

On Thu, Nov 12, 2009 at 10:52:03AM -0800, Love Hörnquist Åstrand wrote:
> 12 nov 2009 kl. 09:04 skrev Nicolas Williams:
> > I'd love to see that, please :)
> 
> http://www.opengroup.org/onlinepubs/009695399/functions/fork.html
> 
> "A process shall be created with a single thread. If a multi-threaded
> process calls fork(), the new process shall contain a replica of the
> calling thread and its entire address space, possibly including the
> states of mutexes and other resources. Consequently, to avoid errors,
> the child process may only execute async-signal-safe operations until
> such time as one of the exec functions is called. [THR] 

>   Fork handlers may be established by means of the
>   pthread_atfork()function in order to maintain application invariants
>   across fork() calls."
> 
> Does libc regiester all mutexes it uses with pthread_atfork() so
> malloc will continue to work ? As long as all libraries doesn't you
> pthread_atfork() you are dead.

If there are libraries in OpenSolaris that use threads but don't clean
up their synchronization state in fork() children via pthread_atfork(),
then that's _BUG_.  I'll grant that some such libraries may not be part
of core Solaris, that they may be FOSS with upstreams that don't care
about such bugs.  But here we're talking about libraries (GSS-API
mechglue and providers) that are part of core Solaris.

> Fork-and-not-do-exec is dead concept in multi threaded apps.

Fork-and-not-exec is a suspect idea no matter what, and if you'll
fork-and-exec then you should use posix_spawn(3C).

But why is any of this a concern here?  Does Samba fork-and-not-exec?
Are you afraid that there are libraries that would?

Nico
--