[M3devel] cvsup

[Olaf Wagner]

Quoting Jay K <jay.krell at cornell.edu>:

> Here's a shorter more direct version.
>
> Please start here:
> http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
>   "There are at least two serious problems with the semantics of   
> fork() in a multi-threaded program"
>
> I have a good theory as to the problem and the fix.
>
> Problem:
>
> With user threads, when you fork(), all the threads keep running in   
> the new child.
>
>    Because the data that causes them to exist is carried forward.
>
> With kernel threads, they don't, just the caller of fork().

This is where I seem to have been wrong. I always thought that fork()
would indeed duplicate all threads and their execution states.

> Fix:
>
>   A few small uses of pthread_atfork both in m3core and cvsup.
>
>   Abstracted behind Thread.PThreadAtFork that does nothing for user   
> threads and Win32.
>
>   They would do things like "reinitialize globals" and "recreate   
> worker threads".

This sounds reasonable, but is of course not trivial.
I think we should at least guarantee that the M3 runtime threads
that were running are available again and will do their work.

I'm not sure if cvsupd itself will need application extensions, or if
the threads handling the streaming protocol are created after the fork.

John Polstra used to be on this list and may be able to help.

Olaf
-- 
Olaf Wagner -- elego Software Solutions GmbH
                Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
    http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194