Am 02.05.2014 16:09, schrieb Luís Marques:
On Fri, 02 May 2014 12:11:23 GMT, Sönke Ludwig wrote:
The issue is caused by the order or module destructors:
- vibe.core.core's
~static this
is called, cleaning up the event driver- the application's
~shared static this
is called, failing to close the connection, because the driver is already destroyed- vibe.core.core's
~shared static this
would be called, performing the final clean up of vibe.dI've implemented a workaround that delays the deletion of the main event driver to step 3, which fixes the issue (and hopefully doesn't introduce new ones ;)
Anyway, how would a sound / long-term design solve that? Should apps register their destructors with vibe.d? Should D implement some kind of module destructor dependency mechanism? Ideas?
D already implements such a mechanism, it's just that all per-thread
destructors are run first, but the individual module destructors of each
type are always called in dependee-first order (and the constuctors in
dependecy-first order). So I'd say that this fix is all that is needed.
It should completely hide the destruction of the driver from the
application now.