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:
crs 2004-07-29 21:48:40 +00:00
parent 970c8b2fba
commit ef85356f45
1 changed files with 1 additions and 1 deletions

View File

@ -442,7 +442,7 @@ CTCPSocket::serviceConnecting(ISocketMultiplexerJob* job,
// connection refused. when that happens it at least doesn't // connection refused. when that happens it at least doesn't
// report the socket as being writable so synergy is able to time // report the socket as being writable so synergy is able to time
// out the attempt.) // out the attempt.)
if (true || error) { if (error || true) {
try { try {
// connection may have failed or succeeded // connection may have failed or succeeded
ARCH->throwErrorOnSocket(m_socket); ARCH->throwErrorOnSocket(m_socket);