Worked around bug/weirdness on OS X. It's reporting that a
non-blocking connect is available for writing (i.e. the connection was successful) when the connection has actually failed. This caused synergy to rapidly retry connecting. This change makes synergy check for a connection error whether one was reported or not. Thankfully, OS X does correctly set the socket error state when it bogusly reports a successful connection so we can tell the connection failed.
This commit is contained in:
parent
970c8b2fba
commit
ef85356f45
|
@ -442,7 +442,7 @@ CTCPSocket::serviceConnecting(ISocketMultiplexerJob* job,
|
|||
// connection refused. when that happens it at least doesn't
|
||||
// report the socket as being writable so synergy is able to time
|
||||
// out the attempt.)
|
||||
if (true || error) {
|
||||
if (error || true) {
|
||||
try {
|
||||
// connection may have failed or succeeded
|
||||
ARCH->throwErrorOnSocket(m_socket);
|
||||
|
|
Loading…
Reference in New Issue