#2412 Plot window freezes if stdin is not a console (Windows build).

[Takashi Yano]

Version

Version: 5.4.1 (mingw windows build: gp541-win64-mingw.7z)
OS: Windows 10 20H2 (64 bit)

The issue

The plot window freezes if stdin is not a console.

How to reproduce

1. In command prompt, execute set GNUTERM=windows
2. execute type con | gnuplot
3. enter plot sin(x)
4. Try to move or resize the plot window.

If stdin is console (not a pipe), the problem does not occur. This also occurs with current git head (ceba2fa7054d001b4ababacf9cef23f9d89f4a9a), while version 5.2.8 works fine without the problem.

[Takashi Yano]

I found this issue occurs after the commit:

commit 651af6267b0270a71c6e0c0c2345f2c01a68eea6
Author: Bastian Maerkisch bmaerkisch@web.de
Date: Sat Jan 25 13:34:13 2020 +0100

Wait for pipe events without additional thread

Previously, we would start a new thread for every single character
in a pipe, making it very inefficient. This is not really necessary,
we can just call MsgWaitForMultipleObjects() with the stdin handle
directly.

Bug #2204

Reverting this commit solves the issue.

[Takashi Yano]

I wonder if it is the correct manner waiting for pipe handle using MsgWaitForMultipleObjects().

https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-msgwaitformultipleobjects says MsgWaitForMultipleObjects() cannot be used with pipe handle.

[Bastian Märkisch]

It does not say it cannot be used with pipes, but does not list them explicitly in the list of allowed types ;). It works fine with piped input, like cat simple.dem | gnuplot or yes | gnuplot simple.dem. Also in your case the pipe itself works fine. But processing the message queue commands seems not to work. In your case, these do no longer trigger MsgWaitForMultipleObjects(). Interestingly, echo plot x; pause mouse; quit | gnuplot works as expected. This uses nearly the same code in win_sleep().

[Takashi Yano]

The same issue happens with:

• (cat simple.dem; sleep 100) | gnuplot
• (echo plot x; sleep 100) | gnuplot

If the handle passed to MsgWaitForMultipleObjects() is a pipe, it can response to pipe input, however, it does not response to window event. Timeout also does not work.

[Takashi Yano]

If the handle passed to MsgWaitForMultipleObjects() is a pipe, it can response to pipe input, however, it does not response to window event. Timeout also does not work.

No. I was wrong. MsgWaitForMultipleObjects() always returns WAIT_OBJECT_0 even if the pipe input is not ready when a pipe handle is passed.

[Takashi Yano]

Due to this issue, gnuplot cannot be used as graphics toolkit for GNU octave any more.

[Armin Armbruster]

I have the same or a similar problem.
I'm using gnuplot in combination with ruby (using the gem gnuplot-2.6.2).
Everything works fine with gnuplot 5.2.8, but when I install gnuplot 5.4.1 ruby "hangs" and no plot window opens (or no file is generated).
In Windows Task Manager I can see that an instance of gnuplot is created.
Unfortunately for me this means that I had to go back to gnuplot 5.2.8 until this is resolved.

[Bastian Märkisch]

I think I finally have pushed a reasonable solution to the 5.5 master branch: We keep the thread for pipe input and signal to the main event via an event object on new input. Please let me know if that fixes it.

[Takashi Yano]

I have confirmed that the issue has been fixed in the current git head.

Thanks for working on this.

[Bastian Märkisch]

Great. Thanks for the confirmation. Sorry that it took so long.