Re: ORBit2 native Win32 port progress

[Tor Lillqvist <tml iki fi>]

Andrewlanoix aol com writes:
 > Tor, GNet requires Winsock2. Would that be an issue?

Nah, I don't think so. Not a big deal to require Winsock 2. (And one
could even do some LoadLibrary()/GetProcAddress() hacks so that GLib
would first try to load ws2_32.dll, and on those few machines without
ws2_32.dll, it would then load winsock.dll instead and use only that
API which was available in Winsock 1.)

 > I now understand that GPollFD::fd should not be required to be a
 > HANDLE, it should also work with a socket etc. As you said, this
 > will require a significant redesign.

Yes. I am working on it. For a start, here is the rewritten comment
for GPollFD in gmain.h:

 * On Windows, the fd in a GPollFD can either be file descriptor as
 * provided by the C runtime library MSVCRT.DLL, a SOCKET from
 * WinSock, a window handle (HWND), or a HANDLE for an object. (A
 * HANDLE should be one of those that can be used by the
 * WaitForSingleObject, WaitForMultipleObjects or
 * MsgWaitForMultipleObjects functions. This does not include file or
 * pipe handles, for instance.)
 *
 * On Windows, fd can also be the special value G_WIN32_MSG_HANDLE to
 * indicate polling for messages for any window in the current thread.
 *
 * It is possible, even though perhaps not likely in most
 * applications, that the same numerical value will be both a valid
 * file descriptor and a SOCKET. (But presumably not HWMD or HANDLE.)
 * To guard against this kind of overlap and guarantee that GLib does
 * what you mean, don't set the fd field of GPollFD in your code, but
 * use the function g_pollfd_set_fd(). On Windows, this sets the fd to
 * an internal magic value recognized by GLib, with associated type
 * information.

To enable programs/libs to avoid the risk of overlapping file
descriptors and sockets, this new enum and function would be added:

typedef enum
{
  G_POLLFD_FILE_DESCRIPTOR,
  G_POLLFD_SOCKET,
  G_POLLFD_WIN32_HWND,
  G_POLLFD_WIN32_HANDLE
} GPollFDType;

void          g_pollfd_set_fd (GPollFDType type,
			       gint        fd
			       GPollFD    *pollfd);

On Unix, g_pollfd_set_fd() would trivially set pollfd->fd = fd. On
Windows, it would set pollfd->fd to a magic cookie that would then in
the Windows g_poll() implementation be handled specially and used to
deduce what kind of fd it is.

The risk of overlap between file descriptors and sockets isn't
entirely theoretical. File descriptors, at least in the current
msvcrt.dll, are in the range 0..2047. The lowest socket value I
noticed in a test program is 512. It's not hard to imagine that some
kind of long-running server application might might have over 512
files open (at least if it forgets to close files...), and also lots
of sockets. Of course, very few of the fds would presumably be
g_poll()ed on, but if the program when it already has 512 fds open,
then opens a pipe that it would like to g_poll(), the pipe fds might
well clash with sockets.

--tml