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] |
On May 3 19:03, Ryan Johnson wrote: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]).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?
Thoughts? Ryan
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |