dub run leaves behind temp files

[MartinNowak]

Found a huge amount of dub temp files in my /tmp/ folder.
Seems like dub relies on static ~this() to cleanup temp files, but that is never called if you dub run a tool and exit it via CTRL+C.

[mihails-strasuns]

This must be a side effect of my attempt at tmp file randomization. I did put all removal in one place there because original way felt overly error prone - some bits of code did remove files but ones that were rarely called sometime forgot it.

I am surprised module destructors are not being run upon receiving SIGINT. It is not a critical signal like SIGABRT and resource cleanup should be done as normally. This sounds like druntime bug.

[MartinNowak]

You can't do much in a signal handler (because you might easily dead-lock) and installing a signal handler to perform cleanup comes with a lot of other difficulties, e.g. inadvertently catching SIGINT from a child, overriding other handlers. It's not something you want to add to druntime (atexit doesn't seem to run either).
Seems like this mostly happens with dub run, so the SIGINT is actually meant to terminate the child process but kills dub as well.

[mihails-strasuns]

One option could be to simply set internal druntime flag in sigint handler and check it upon entering any druntime function (SIGINT does not specify how soon application must terminate, it is allowed to even ignore it). I understand that there is no easy & clean solution here but just accepting existing situation makes destructors even more useless than they normally are (I kind of accepted lack of class destructors but this also removes struct and module ones)

[MartinNowak]

Related, sometimes dub leaves .lock files behind, apparently when getting killed (SIGABRT?) during fetching a package. Those block (timeout) later attempts to retrieve that package and need manual intervention.
We should use a better lockfile implementation that can deal with dead owners and/or cleanup stuff even on signals.