How to make child of failed fork exit cleanly?

[Ryan Johnson]

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]).

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?

There's also the question of what to do if a child_copy ever fails 
partway through. I assume it would only be a problem if things get 
really messed up, in which case failing to run finalizers on some dlls 
is the least of the user's worries.

Thoughts?
Ryan