How to make child of failed fork exit cleanly?

[Corinna Vinschen]

On May  4 10:34, Ryan Johnson wrote:
> On 04/05/2011 5:25 AM, Corinna Vinschen wrote:
> >On May  3 19:03, Ryan Johnson wrote:
> >>On 03/05/2011 2:41 PM, Corinna Vinschen wrote:
> >>>I'm not sure I understand the question.  How do you know which
> >>>DLL is already initialized and which isn't?
> >>I'm talking about a call to dll_list::alloc, due to a DLL_LINK which
> >>did not map to its parent's address. At this point we know the fork
> >>has failed and there's no point continuing to try.
> >>[...]
> >>For the moment I've just disabled all finalizers if in_forkee=1, on
> >>the premise that it's better to risk not runing a valid finalizer
> >>than to risk running an invalid one. That made the access violations
> >>go away, [...]
> >Can't we mark the DLLs in the list for which the constructors ran
> >successfully and only call them on termination?
> I thought the same thing -- dlls are supposed to init/finalize
> properly even if their dependencies aren't around -- but it may not
> always work. Problem is, the dll state copied over from the parent
> reflects a process well past initialization time, when dlls are
> allowed to communicate with each other and share state, but if a
> fork fails, finalizers which run can find that some of that shared
> state is not valid (because the corresponding dll failed to load [in
> the right place]).

The problem here is, we don't have the entire process in our own hands.
If something can go wrong, it will under some condition and you have a
hard time to predict it.  As long as we try to behave as sane as
possible in the circumstances, we should be fine.

The ultimate solution to the fork problem is not exactly a short-term
solution.  What we would have to do is to get rid of any static linking
for Cygwin DLLs, and to get rid of the LoadLibrary call in dlopen,
and to implement our own loader instead.  And then, SHTDI.

> That said, I've implemented what you suggested (reversing the sense
> of dll::has_dtors until fork fixup completes), and it seems to
> behave properly. I still wonder, though: can we expect all dlls to
> behave properly if (from their perspective) some library they
> communicate with has ceased to exist without detaching?

It's a good assumption for a start.  If it turns out to be incorrect,
we can take another look.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat