Re: windows [Re: Review of gnio, round 2]

[Alexander Larsson <alexl redhat com>]

On Fri, 2009-05-08 at 14:10 -0400, Dan Winship wrote:
> I feel like, as much as possible, GSocket should behave the same on
> Linux and Windows. So I'm dubious about a few things...
> 
> blocking/non-blocking: "on Windows it is not possible to read the
> non-blocking property of a socket so it won't be reliably detected", and
> "on windows any call to g_socket_create_source(),
> g_socket_condition_check(), or g_socket_condition_wait() will
> automatically enable non-blocking mode". Yuck! Would it be possible to
> just always set winsock sockets to non-blocking mode, and implement
> GSocket's blocking flag entirely at the GSocket level, by calling
> g_socket_condition_wait() internally at the right times if
> socket->priv->blocking is set?

The not-possible-to-read-non-blocking thing only affects
g_socket_new_from_fd(), so Its not a horrible problem. Although I agree
that its kinda weird. Its clearly possible to implement blocking mode on
win32 purely on the gsocket.c side, which would make GSocket behave
similar on win32 and unix, however things using g_socket_get_fd() to do
platform specific things may be surprised when their blocking sockets
return EWOULDBLOCK.

> g_socket_set_reuse_address: Huh? I'd thought we agreed that this should
> always be set on unix, and never on windows, and people can use system
> calls if they need the other behavior. This is essentially two
> completely different methods on unix and windows right now...

I thought about this some more, and I think its perhaps not such a good
idea to always set it. For *server* sockets its generally always safe to
set it, since the chances of problems is low. We can run into problem is
another connection has the same (source ip, source port, dest ip, dest
port) tuple, which is unlikely even if dest ip and port is reused.

However, for a client socket, i think there is a potential for two
consecutive connections to one dest ip/port with SO_REUSEADDR set to get
the same source port and thus confuse the old connection and the new.

However, I agree that its kinda iffy that the win32 version does
something completely different... Maybe we can just make the win32
version a no-op (since win32 already does SO_REUSEADDR more  or less).