Write to StdOutput/StdError stream should never blocks LINQPad running
For following code:
void Main1() // Hit Alt+Shift+1 to run { Console.WriteLine("Test std-output"); using Stream stream = Console.OpenStandardOutput(); WriteStream(stream); } void Main2() // Hit Alt+Shift+2 to run { Console.WriteLine("Test std-error"); using Stream stream = Console.OpenStandardError(); WriteStream(stream); } void WriteStream(Stream stream) { stream.Write(Encoding.Unicode.GetBytes(new string('A', 2047))); // 2047, OK Console.WriteLine("2047 OK"); stream.Write(Encoding.Unicode.GetBytes(new string('A', 1))); // 2048, OK Console.WriteLine("2048 OK"); stream.Write(Encoding.Unicode.GetBytes(new string('A', 1))); // 2049, Blocks NOT OK Console.WriteLine("2049 NOT OK"); }
These 2 actions blocks LINQPad scripts running forever, I believe this should be not a expected behavior. Especially in scenarios that calls native library such as FFmpeg/x264, which uses fputs(str, stdout) for example.
(I'm not asking to redirect StdOutput/StdError into LINQPad result window, there might be some technical difficulties, I'm asking LINQPad not been blocked/deadlocked by these seems "normal" actions)
This could be the major different between LINQPad and Visual Studio in my working scenario, I took a lot of time and finally identified the issue, please take some time and try fix it ASAP.
LINQPad version: LINQPad 6.10.11(X64) Beta -Fx=5.0.0-rc.1.20452.2
I tried LINQPad 5, looks like the buffer is 4096 instead of 2048, but also blocks.
Comments
Try the latest beta and let me know if it's still a problem.
Yes, it works for me, thanks a lot