Call to Runtime.unloadLibrary corrupts stdout and stderr
Rainer Schuetze via Digitalmars-d
digitalmars-d at puremagic.com
Sun Sep 3 13:07:26 PDT 2017
On 03.09.2017 20:21, Markus Pursche wrote:
> On Sunday, 3 September 2017 at 13:41:33 UTC, Rainer Schuetze wrote:
>> On 02.09.2017 23:38, Markus Pursche wrote:
>> Unfortunately, this section only applies to simple programs (no
>> multi-threading, no sharing of other resources than GC-memory, not
>> even malloc'ed memory). I think there should be a big red warning at
>> the beginning of that section.
>> Proper DLL support for Windows (with a shared phobos library) is
>> slowly being worked on, see http://dconf.org/2016/talks/thaut.html
>> In the mean time, I prefer keeping DLL resources completely separate,
>> as shown in
>> You are probably hitting
>> https://issues.dlang.org/show_bug.cgi?id=1550, so try the workaround:
>> import std.stdio and add "_fcloseallp = null;"
>> somewhere in your DllMain.
> This worked! So, is there any chance that you could tell me why this
> isn't the default behavior from the start? Like is there a reason for it
> not to be there automatically, like a performance loss or a leak or
This workaround has side effects, i.e. it doesn't automatically close
any file still open by the DLLs' instance of the C runtime, so it might
cause incomplete files if someone relies on these being automatically
flushed and closed.
It's a bug in the dmc runtime. Only Walter can fix it as it is closed
More information about the Digitalmars-d