Re: g_source_add_poll or g_io_add_watch in Windows?

["Tor Lillqvist" <tml iki fi>]

> IIRC there's a different handling in win. Sockets have their own fd, but it's not pollable...

Please be more careful in your terminology, and don't generalise too much.

Sockets on Windows are not "fds" (file descriptors) (which on Windows
means something known to the C library, only (and note that there are
several alternative C libraries even, eek!)).

What you mean with "not pollable" is quite unclear, too. Do you mean
poll()? There is no poll() function in Windows. Do you mean select()?
Yes, select() works fine on Windows. You can even have non-blocking
sockets that work quite like on UNIX. But note that on Windows
select() is *only* for sockets. And if you want to use Win32 APIs to
"poll" sockets, that works fine, too, if you associate a so-called
event with the socket using the function WSAEventSelect(). You can
then use the normal WaitFor* family of functions to "poll" the socket.

In general, if one writes Windows-specific code, it is possible to do
more or less the same stuff as on UNIX. The low level code will be
completely different, but the net effect achievable from a high level,
more abstract, point of view will be more or less the same. That
doesn't help much in GLib's case, though, because its API has been
designed from a UNIX point of view, and it exposes a bit too much of
how things can be done on UNIX. For instance accepting sockets and
file descriptors directly, thus requiring the calling code to create
them in advance, and allowing the calling code to do things with them
without GLib knowing.

> Or use an abstraction library (GNet?).

That might be a good idea, as long as you use a new enough version of
GNet that actually works well on Windows. I haven't paid attention to
GNet in a long time, but at least at some stage it was broken on
Windows. I *think* it was fixed, though. (I submitted some patch
myself.)

--tml