digitalmars.D.bugs - [Issue 4104] New: No way to get notified about D runtime termination.
- d-bugmail puremagic.com (68/68) Apr 19 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4104
- d-bugmail puremagic.com (13/13) Jul 20 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4104
- d-bugmail puremagic.com (19/19) Jul 22 2010 http://d.puremagic.com/issues/show_bug.cgi?id=4104
http://d.puremagic.com/issues/show_bug.cgi?id=4104 Summary: No way to get notified about D runtime termination. Product: D Version: unspecified Platform: Other OS/Version: Linux Status: NEW Severity: critical Priority: P2 Component: druntime AssignedTo: sean invisibleduck.org ReportedBy: samukha voliacable.com PDT --- Qt classes have corresponding D wrappers in QtD. For many Qt classes we can avoid creating duplicate wrappers (or searching a wrapper cache) and store the D wrapper pointers directly in the C++ objects. When Qt takes ownership of such an object, QtD disables garbage collection for the D wrapper by adding its reference to the GC roots. When later Qt deletes the object, a callback to D is emitted, during which the wrapper is destroyed. Everything works well unless the C++ object is statically allocated or is owned by a statically allocated object. If it is, the C++ destructor is called *after* the D runtime has been terminated, meaning GC pools has been freed and there is no wrapper to delete. One solution is to have a flag that would be set after the D runtime has been terminated. Then we could avoid deleting already freed wrappers by checking the flag in the callback. Patch for druntime/src/rt/dmain2.d: -165,12 +165,18 } shared bool _d_isHalting = false; +shared bool _d_isTerminated = false; extern (C) bool rt_isHalting() { return _d_isHalting; } +extern (C) bool rt_isTerminated() +{ + return _d_isTerminated; +} + // This variable is only ever set by a debugger on initialization so it should // be fine to leave it as __gshared. extern (C) __gshared bool rt_trapExceptions = true; -244,6 +250,7 finally { _d_criticalTerm(); + _d_isTerminated = true; } return false; } -404,5 +411,7 _STD_critical_term(); _STD_monitor_staticdtor(); } + + _d_isTerminated = true; return result; } Another solution would be a notification. Tests show that 'atexit' doesn't work for us because the handlers registered with 'atexit' are invoked after the destructors has been run. So we need a separate notification. Even better solution: don't free the GC memory on exit and give the rooted objects a chance to be finalized properly. This is critical. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 19 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4104 Sean Kelly <sean invisibleduck.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Is this something that can be addressed via a shared module dtor, or is that too early/late in the termination process? isHalting seems of limited utility so I tentatively deprecated it, but perhaps it should be replaced by a status field instead? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 20 2010
http://d.puremagic.com/issues/show_bug.cgi?id=4104 PDT --- I am afraid it is too early. The problem is that during the final GC cycle wrappers owned by D (subject to garbage collection) will be destroyed. As part of their destruction process, they will destroy their corresponding C++ objects, which may destroy other C++ objects, which will destroy their D wrappers (those added to roots). Though I am not entirely sure whether the last-mentioned wrappers need to be destroyed at program exit, I tend to think they do, just like the wrapper that owns them (that is the one that indirectly causes their destruction). From the above follows that we need to know when the final GC cycle has been finished, so that QtD doesn't try to destroy wrappers for the C++ objects that survived that cycle. Obviously isHalting does not help here because it is set before the GC cycle is initiated. A field of an enum type indicating the current runtime state would be great. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 22 2010