https://issues.dlang.org/show_bug.cgi?id=19978
RazvanN <razvan.nitu1...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |razvan.nitu1...@gmail.com
--- Comment #4 from RazvanN <razvan.nitu1...@gmail.com> ---
(In reply to FeepingCreature from comment #3)
> Okay, got it.
>
> The problem is with a daemon thread, D doesn't join it when shutting down.
> As a result, the GC shutdown sequence deletes the thread's memory right
> under it.
>
> Why do we do this anyway? (gc_term>os_mem_unmap) Why not let the OS handle
> the frees?
The problem is that we have (shared) static constructors/destructors to worry
about. Currently, I haven't found any information about the behavior of daemon
threads in the presence of module constructors, however, my expectation is that
the behavior should be the same as with normal threads (although one could
argue that this goes against the spirit of daemon threads - you create them and
then you stop caring about them). If we just let the OS do the cleanup then we
will not be able to call the static destructors.
I see 2 possible solutions to this:
1. Before tearing down the process, we just stop the daemon threads and call
static destructors. Since the program is exiting, I don't see a problem since
the OS would stop them anyway.
2. Daemon threads do not call static destructors (in the spirit of not caring
about them) - I don't really like this since it deviates from the general rule.
Essentially, once you start tearing down the process, you cannot allow daemon
threads to run, if you hope for graceful exit.
--
