Re: socket handling patch for glib-win32

[Ralph Giles <giles thaumas net>]

On Sat, Apr 30, 2005 at 05:41:21AM +0300, Tor Lillqvist wrote:

> 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 .

Oops! Just saw that after my post. We're trying to test that fix as 
well, but are having trouble getting 2.6.7 to build on win32 at all. 
Is HEAD a better proposition?

> 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.

Yes, that would be confusing. We use them in non-blocking mode, except 
(I think) inside GNU TLS, so it will probably work for us. As far as 
the best behaviour goes, I'm not informed enough to have an opinion
at this point. :)

> 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...

Aha.

>  > 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...

Yes, folks pointed me at GNet on irc. Maybe just moving the socket 
abstraction from there into GLib is an idea. At least we're not the 
first to think of it...

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

Well, this is rather my point. The APIs are functionally very similar, 
so designs port well, but everyone who wants to do cross-platform 
network programming has to write their own little abstraction (or 
#ifdef everything) to call WinSock API on Windows and the BSD socket
API everywhere else. That's the part GLib should take care of.

> 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.

Right, and the io_channel abstraction provides a nice way around that. 
There's just no g_socket(),g_connect() or g_io_channel_new_socket(). 
Perhaps I'm too inexperienced to see all the issues, but a library
that wraps fopen() just to deal with i18n shouldn't have a problem 
here. :)

Thanks for answering,
 -r