We use native paths now in wxWindows. On the Mac, too.

[wxWidgets.git] / src / common / socket.cpp

diff --git a/src/common/socket.cpp b/src/common/socket.cpp
index a3eec9aae2d8f2716c6ba41ade5cecb286fe1e8a..7ec0743ec109a5a7ad75c44cd1dca9ba881248a2 100644 (file)
--- a/src/common/socket.cpp
+++ b/src/common/socket.cpp
@@ -51,12 +51,30 @@
 // discard buffer
 #define MAX_DISCARD_SIZE (10 * 1024)
 
-// what to do within waits
+// what to do within waits: in wxBase we don't do anything as we don't have
+// the event loop anyhow (for now). In GUI apps we have 2 cases: from the main
+// thread itself we have to call wxYield() to let the events (including the
+// GUI events and the low-level (not wxWindows) events from GSocket) be
+// processed. From another thread it is enough to just call wxThread::Yield()
+// which will give away the rest of our time slice: the explanation is that
+// the events will be processed by the main thread anyhow, without calling
+// wxYield(), but we don't want to eat the CPU time uselessly while sitting
+// in the loop waiting for the data
 #if wxUSE_GUI
-  #define PROCESS_EVENTS() wxYield()
-#else
-  #define PROCESS_EVENTS()
-#endif
+    #if wxUSE_THREADS
+        #define PROCESS_EVENTS()        \
+        {                               \
+            if ( wxThread::IsMain() )   \
+                wxYield();              \
+            else                        \
+                wxThread::Yield();      \
+        }
+    #else // !wxUSE_THREADS
+        #define PROCESS_EVENTS() wxYield()
+    #endif // wxUSE_THREADS/!wxUSE_THREADS
+#else // !wxUSE_GUI
+    #define PROCESS_EVENTS()
+#endif // wxUSE_GUI/!wxUSE_GUI
 
 // --------------------------------------------------------------------------
 // wxWin macros
@@ -463,7 +481,7 @@ wxUint32 wxSocketBase::_Write(const void *buffer, wxUint32 nbytes)
   {
     bool more = TRUE;
 
-    while (more)            
+    while (more)
     {
       if ( !(m_flags & wxSOCKET_BLOCK) && !WaitForWrite() )
         break;
@@ -477,18 +495,6 @@ wxUint32 wxSocketBase::_Write(const void *buffer, wxUint32 nbytes)
         buffer  = (const char *)buffer + ret;
       }
 
-      // Yes, this can happen even when the socket selects as writable!
-      // (probably due to a buggy kernel; Linux 2.0.36 seems to do this).
-      // Fake it so that we stay in the loop, but do it only for ret < 0,
-      // as ret == 0 means that the socket is closed. I'm not applying
-      // this hack for read calls as it seems unnecessary there.
-      //
-      if ((ret < 0) && (GSocket_GetError(m_socket) == GSOCK_WOULDBLOCK))
-      {
-        wxLogDebug(_("wxSocket: working around select() bug in Write."));
-        continue;
-      }
-
       // If we got here and wxSOCKET_WAITALL is not set, we can leave
       // now. Otherwise, wait until we send all the data or until there
       // is an error.
@@ -1004,7 +1010,7 @@ wxUint32 wxSocketBase::GetPushback(void *buffer, wxUint32 size, bool peek)
 
 
 // ==========================================================================
-// wxSocketServer                             
+// wxSocketServer
 // ==========================================================================
 
 // --------------------------------------------------------------------------
@@ -1082,7 +1088,10 @@ wxSocketBase *wxSocketServer::Accept(bool wait)
   sock->SetFlags(m_flags);
 
   if (!AcceptWith(*sock, wait))
-    return NULL;
+  {
+    sock->Destroy();
+    sock = NULL;
+  }
 
   return sock;
 }
@@ -1254,7 +1263,7 @@ class WXDLLEXPORT wxSocketModule : public wxModule
   DECLARE_DYNAMIC_CLASS(wxSocketModule)
 
 public:
-  bool OnInit() { return GSocket_Init(); }
+  bool OnInit() { return GSocket_Init() != 0; }
   void OnExit() { GSocket_Cleanup(); }
 };