The refactoring in the commit 51ea713826 (Extend and rename
wxSocketImpl::UnblockAndRegisterWithEventLoop(), 2019-11-20)
accidentally inverted the test for wxSOCKET_BLOCK, restore the correct
logic to make non-blocking sockets work again.
Closes#18834.
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.
It should still be possible to use DoEnableEvents() to disable events
for blocking sockets and this can be useful if a previously non-blocking
socket became blocking due to a SetFlags(wxSOCKET_BLOCK) call, so adjust
the fix of e18c8fd29a (see #17031) to
avoid calling EnableEvents() for blocking sockets instead of ignoring
them in DoEnableEvents() itself.
Also add an assert checking that we never try enabling events for
blocking sockets as this still doesn't make sense and so shouldn't
happen.
No real changes yet, but this is necessary for the upcoming commits.
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.
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
Include sys/filio.h to define FIONBIO in all cases (sometimes this header is
already included from sys/ioctl.h but not always).
Closes#12481.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@65581 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This fixes linking problems under Unix introduced by recent changes which
fixed previous problems which were due to files not being linked in at all.
In order to provide a clean separation between base, net and core libraries we
now use the same wxSocketManager (wxSocketFDBasedManager), defined in net
library for both console and GUI Unix applications and just use different FD
IO manager for them: the latter can be defined in base and core libraries as
it doesn't involve wxSocketImpl at all, only its base wxFDIOHandler class.
At more detailed level, these changes required:
1. Adding the new wxFDIOManager class.
2. Refactoring the old (and now removed) wxSocketFDIOManager to use the same
code as wxSocketFDIOManager. This involved:
a) Adding handler and direction parameter to RemoveInput().
b) Storing the mask of registered events in wxFDIOHandler itself.
c) Defining wxFDIOManagerUnix which works with wxFDIODispatcher.
3. Changing the traits classes in Unix ports to define GetFDIOManager()
instead of GetSocketManager().
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61688 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This will allow to use the base wxFDIOHandler class only in GUI-specific
network code and this remove its dependency on wxSocketImplUnix. IOW it paves
the way for a proper solution of the problem fixed by r61336 without the hack
of r61335 which results in linking problems (which went undiscovered until now
but were, in fact, always present, i.e. r61335 couldn't work).
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61685 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This is necessary to create different kinds of sockets for the console and GUI
applications under OS X: unlike Unix which use different socket managers for
the console and GUI programs but still use the same data structures in both
cases as X11 and derived toolkits APIs are very similar, Core Foundation
sockets don't have anything in common with their console counterparts and so
we need to use different wxSocketImpl versions too.
A side effect of this commit is that now we need to force linking of
src/msw/sockmsw.cpp when using sockets: this wasn't necessary before because
it contained wxSocketImpl method definition but now that there are no more
direct dependencies on it, MSVC linker simply discards the object file unless
we force it to link with it.
Notice that this commit doesn't change anything yet, it simply refactors the
code to use wxSocketManager::CreateSocket() instead of wxSocketImpl::Create()
in preparation for the next change.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@61675 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
