On Wed, 13 Mar 2019, Tatsuro MATSUOKA wrote:
[...]
>>>  I have prepared binaries:
>>>  http://tmacchant3.starfree.jp/gnuplot/Eng/cyg_qt_test/
>>>
>>>  test
>>>  From gnplot prompt
>>>
>>>  gnuplot> set terminal qt
>>>  gnuplot> plot x
>>>
>>>  Without Qt patch
>>>
>>>  Could not connect to existing gnuplot_qt. Starting a new one.
>>>
>>>  Warning: slow font initialization
>>>
>>>
>>>
>>>  With Qt patchplot appears
[...]
> One note: for gnuplot.exe and gnuplot_qt.exe, debug symbols are not stripped and 
> you can trace gdb but I did not know debug info for Qt.

I believe I've found the root cause of this issue of outbound connect on a 
non-blocking socket not working under Cygwin.

It's in Qt's qlocalsocket_unix.cpp.  On line 285 there's a call to 
qt_safe_connect().  At this point the socket fd has already been set 
non-blocking.  Within qt_safe_connect() there's a call (eventually) to 
Cygwin's connect().  That connect() is returning -1 with errno set to 
EINPROGRESS.

Back in qlocalsocket_unix.cpp, line 287 does a 'switch(errno)' but doesn't
have a case for EINPROGRESS.  That error condition reaches the 'default:'
case, returning without the connection being completed.  I don't know why 
there's no error report to the user.

Note that you don't want to quick-fix this by adding a 'case EINPROGRESS:'
that simply acts like the connection is completed.  I think somebody who 
knows Qt network internals will have to develop a real fix.

It seems nobody has run across a non-blocking connect() that doesn't 
immediately complete connection.. but Posix mandates an EINPROGRESS error 
in that situation so Cygwin appears to be doing the right thing.

..mark