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:

  1. vibe.core.core's ~static this is called, cleaning up the event driver
  2. the application's ~shared static this is called, failing to close the connection, because the driver is already destroyed
  3. vibe.core.core's ~shared static this would be called, performing the final clean up of vibe.d

I'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.