Sockets returned by wxSocket::Accept() are non-blocking by default and
the only way to use them safely in worker threads is by switching them
to the blocking mode by calling SetFlags(wxSOCKET_BLOCK).
However this didn't work correctly since at least 2.8 days, as turning
wxSOCKET_BLOCK on didn't unregister the socket from the event loop, with
which it had been registered on creation. Fix this by doing this now,
which ensures that the main thread doesn't get any notifications about
the socket if it's used, in a blocking way, in a worker thread.
Note that making the new socket blocking after accpeting is still pretty
inefficient and pre-creating the socket as blocking and using
AcceptWith() is still preferable, but at least it does work now.
Closes#12886.
In addition to unblocking and registering the socket, also support using
this function to make the socket blocking and unregistering it from the
event loop, if its flags include wxSOCKET_BLOCK.
This was already half-done by wxMSW, which took wxSOCKET_BLOCK presence
into account in its implementation, but not by the Unix implementation.
Now do it under all platforms, as this will be useful for switching a
previously non-blocking socket to blocking mode.
Finally, rename the function to better reflect what it really does.
See #12886.
If accepting a socket connection failed, wxSocketImpl::Accept() used
close() to close the socket even under MSW, but it can be only used for
the file descriptors there and closesocket() must be used instead for
the sockets.
Add new (private) wxCloseSocket define and use it both here, to fix the
bug, and elsewhere to make the code more clear.
Closes#18407.
Use __ms_u_long instead of just u_long with Cygwin to avoid mismatch
between (64 bit) Cygwin long and (still 32 bit, even in 64 bit build)
Windows API long.
Under MSW calling UnblockAndRegisterWithEventLoop() for blocking sockets
is not only useless, but actually harmful when the socket is used from a
worker thread (which is the common case for blocking sockets), as it
means that the main thread will be receiving notifications for the
socket events and modifying the socket object while it's being used from
the other thread, resulting in data races and general brokenness.
This is similar to e18c8fd29a for Unix
sockets.
Closes#17937.
Windows CE doesn't seem to be supported by Microsoft any longer. Last CE
release was in early 2013 and the PocketPC and Smartphone targets supported by
wxWidgets are long gone.
The build files where already removed in an earlier cleanup this commit
removes all files, every #ifdef and all documentation regarding the Windows CE
support.
Closes https://github.com/wxWidgets/wxWidgets/pull/81
This keyword is not expanded by Git which means it's not replaced with the
correct revision value in the releases made using git-based scripts and it's
confusing to have lines with unexpanded "$Id$" in the released files. As
expanding them with Git is not that simple (it could be done with git archive
and export-subst attribute) and there are not many benefits in having them in
the first place, just remove all these lines.
If nothing else, this will make an eventual transition to Git simpler.
Closes#14487.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74602 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Fixed commented names (path, filename, and extension) of files in include/ and src/. Prepended the names in src/ with "src/" everywhere, while starting those in include/wx/ with "wx/".
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@67254 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
Use "wxWindows licence" and not "wxWidgets licence" (the latter doesn't
exist) and consistently spell "licence" using British spelling.
See #12165.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@64940 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
