This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How to make child of failed fork exit cleanly?


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]