Gabriele Greco writes:
This seems very strange for me since glib 2.8 on Unix does not behave
this way.
Well, Windows isn't Unix, so is it really that surprising that some
things are fundamentally different?
With hindsight it's easy to say that the affected APIs and
abstractions in GLib should perhaps have been designed differently so
that any Unix/Windows differences could have been better hidden. But,
we have to make use of what we have now.
Actually, I think that the original thoughts were that the affected
GLib APIs (GPollFDs, GMainLoop, etc) could have been much more
platform specific. Owen says in bug #120299:
I don't think usage and contents of GPollFD needs to be or
should be portable across Win32/Unix, though changing how
it works is probably an API change on Win32.
My original conception was that GMainLoop would be significantly
different on different operating systems, though GPollFD *
crept into more of the API (g_main_context_query()) for
GTK+-2.x.
That many things then turned out to be implementable on Windows
without requiring ifdefs in GLib-using code was an unexpected positive
surprise. Or something like that...
How can GTK be used as a multiplatform development system if it behave
in different ways for the different platform it supports?
You just have to take those things that behave differently into
account in your code.
Trust me, the implementation of watched GIOChannels for sockets on
Windows in GLib before 2.8 had a wholly different and more serious set
of problems and Unix/Windows differences. Those caused a lot of
problems when porting various GNOME platform libraries to Windows. See
discussion for instance in bugs #120299 and #147392. In the old
implementation there was a separate thread running per watched socket.
So I've to add something like this in my input function (error checking
omitted):
#ifdef WIN32
unsigned long par = 0;
ioctlsocket(fd, FIONBIO, par);
#endif
Actually I don't think that will work. As long as a socket is being
watched (it has an event selection for it (WSAEventSelect()) in force)
you cannot turn the non-blockingness off.
Anyway, as you use GLib mainloop functionality and watched GIOchannels
in the first place, isn't your intention to avoid blocking calls in
your code? You perhaps want to handle reading requests from and
sending replies to multiple sockets in parallel with minimum delay?
Otherwise you could just use blocking recv() and send() all the time
without bothering with GIOChannels and GMainLoops, couldn't you?
So shouldn't you be using non-blocking mode on Unix, too, then? Aren't
you otherwise just knowing your recv()/send() calls won't block
(because they never do in your test environment), and when they then
occasionally *do* block, perhaps indefinitely, in the end-user
environment, you are in trouble?
I've not found anything related to GLIB 2.6 - 2.8 differences at least at:
http://www.gtk.org/api/
Yeah, the documentation needs to have a mention about it added.
--tml
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
