qlocalsocket_unix with O_NONBLOCK is strange on Cygwin

On gnuplot, qt graphics is extablished connect from main process "gnuplot" to other process "gnuplot_qt".

A hack is below required to qlocalsocket_unix.cpp

--- a/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
+++ b/qtbase-opensource-src-5.9.4/src/network/socket/qlocalsocket_unix.cpp
@@ -239,7 +239,7 @@ void QLocalSocket::connectToServer(OpenM
    }
    // create the socket
    if (-1 == (d>connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0, O_NONBLOCK))) {
+    if (1 == (d>connectingSocket = qt_safe_socket(PF_UNIX, SOCK_STREAM, 0))) {
        d->errorOccurred(UnsupportedSocketOperationError,
                        QLatin1String("QLocalSocket::connectToServer"));
        return;

 

O_NONBOLCK does not work on Cygwin.
This topic was discussed in gnuplot ML[1], gnuplot bug[2], and Cygwin ML[3].


[1] https://sourceforge.net/p/gnuplot/mailman/gnuplot-beta/thread/48419791.2058878.1551739068341.JavaMail.yahoo%40mail.yahoo.co.jp/#msg36603526

[2]https://sourceforge.net/p/gnuplot/bugs/2147/

[3] http://cygwin.1069669.n5.nabble.com/Patch-request-to-qt-5-9-4-Re-ANNOUNCEMENT-Qt-5-9-4-td144620.html

In tbe Cygwin ML, Marc sugqest me to create bug tracker in Qt.

I could not make small example to reproduce the phenomena.
Instead, I prepared the Cygwin executable to reporduce the phenomena.


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

The way to install and enviromnetal setup is described 
http://tmacchant3.starfree.jp/gnuplot/Eng/cyg_qt_test/
and
http://tmacchant3.starfree.jp/gnuplot/Eng/cygbin/README_TM.txt

In the Cygwin ML, Mark stated that:

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.

Please give us clues to solve this issue