Re: socket handling patch for glib-win32

[Tor Lillqvist <tml iki fi>]

Ralph Giles writes:
 > We ran into an issue getting the loudmouth XMPP library ported to win32. 
 > As far as we could see, GLib was tearing the socket's io_channel after 
 > the first watch completes, preventing the installation of the remaining 
 > watches and proper handling of stream events in the event loop.

See the discussion bug #147392
(http://bugzilla.gnome.org/show_bug.cgi?id=147392), from comment #11
onwards. Also see
http://mail.gnome.org/archives/gtk-devel-list/2005-April/msg00075.html .

I would like to replace the current implementation of socket
GIOChannels (that uses a thread for each socket) with fresh code that
uses a WSAEventSelect()-based approach instead. Much cleaner code (if
I may say so myself), but it has the drawback that it sets the socket
automatically to non-blocking mode, which apparently might break
existing applications that assume the sockets they open stay in
blocking mode and would be surprised if they turn into non-blocking
sockets.

 > Attached is a patch that just comments out the tear-down, which
 > made things work for us.

The code you are commenting out is exactly what was added in the fix
for bug #147392... I.e. without that, there were thread leaks. But as
you have noticed, and as the discussion in that bug report indicates,
that fix then caused other problems...

 > There's also a larger issue I'd like to mention. I talked to Owen a
 > bit about this on irc, but would like to bring it up here as well.
 > It seems (to us at least) that GLib would really benefit from a
 > socket abstraction api.

Sure! But getting it right, and convincing people to use it might take
time. There are lots of socket abstraction layers built on top of
GLib, each with their own quirks and ideas. I can think of GNet which
is a separate library, plus then there is linc2 in ORBit2, stuff in
libsoup, gnome-vfs, and probably others. It will be hard to harmonize
these and create an über-abstraction, and then convince the
maintainers of the above to switch...

 > but until MS Windows starts supporting the BSD socket API,

Umm, you mean WinSock isn't close enough? IMHO, the differences in API
are rather minor and easy to work around.

What's more problematic is of course that the WinSock API is (well, as
the name says) for sockets and networking only. There is no unified
concept of "file descriptors" of which sockets would be just one kind
in addition to the ones you get from open(). No select() on anything
except sockets. Etc.

--tml