writeln() sometimes double prints from main() if I run a thread checking for input?

[Steven Schveighoffer via Digitalmars-d-learn]

On 8/30/17 9:33 AM, Ivan Kazmenko wrote:
> On Wednesday, 30 August 2017 at 13:24:55 UTC, Ivan Kazmenko wrote:
>> On Wednesday, 30 August 2017 at 10:55:20 UTC, Timothy Foster wrote:
>>> import std.stdio, core.thread;
>>>
>>> void main(){
>>>     auto thread = new Thread(&func).start;
>>>         writeln("Output");
>>>     writeln("Output2");
>>>     writeln("Output3");
>>>     while(true){}
>>> }
>>>
>>> void func(){
>>>     foreach(line; stdin.byLineCopy){}
>>> }
>>
>> I also cannot reproduce this.
>>
>> My current system is Win7 64-bit.  I tried 32-bit dmd 2.072.0 and 
>> 2.075.1, with optimizations turned on and off, but it prints correctly 
>> tens of times in each case.
>>
>> Try running the program in a bare console (cmd.exe on Windows, or some 
>> *sh on Linux).  If the problem goes away, your usual environment is 
>> likely at fault.  If not,.. well, no idea for now.
> 
> Hey, I followed my own advice and do see the same issue! when:
> 1. compiling with dmd 2.075.1 (optimization switches seem to be 
> irrelevant but the issue does not reproduce with 2.072.0),
> 2. running in a bare cmd.exe, and
> 3. running the program as just "a.exe", so that it waits for console 
> input (previously I redirected some input to it, like "a.exe <a.exe" or 
> "a.exe <a.d", and the issue does not reproduce then).
> Interesting.  As to what to do with it, no idea for now.  At the very 
> least we can issue a bug report, now that at least two people can 
> reproduce it, so it is unlikely to be environment-dependent.

Just a thought, but the "double printing" could be a misunderstanding. 
It could be printing Output\nOutput2, but not getting the 2 out there.

Note that DMD 32-bit is using DMC libc. It might be that it gets hung up 
somehow when expecting input, like it locks the console somehow.

I would say that byLineCopy puts the thread to sleep waiting for input, 
and it doesn't get out of that state. So it could be that the bug only 
appears when it gets to that state at some point in the output. I'd 
pepper some sleeps around the outputs to see if you can make the context 
switches more predictable.

-Steve