GNOME Bugzilla – Bug 309241
GIOChannel doesn't signal that a socket is ready to write
Last modified: 2005-07-31 00:03:50 UTC
tested with GLib 2.4.7 & 2.6.5 g_io_add_watch on G_IO_OUT only works immediatley after initial socket connection. If the watch is removed and then added back it does not indicate that the socket is ready for writing. I'll attach a test case.
Created attachment 48486 [details] test-case The program automaticaly shuts down after 5sec. The case will need the name of a news server added in. The expected output is: read response line from server add write watch write The output I get is: read response line from server add write watch
Tested with Glib 2.6.4 and 2.6.5 under Windows 2000 SP4, as packaged by Tor Lillqvist (plus extra adaptation for getaddrinfo, as it is not available under that platform). Exact same behaviour (the news server does reply) of "write" not displaying. I'm wondering if giowin32.c from http://bugzilla.gnome.org/show_bug.cgi?id=147392 can be backported to 2.6 branch and if it could help with this problem.
I now have tested with various versions of Glib. glib 2.4.7 and 2.6.5 patched, still under Windows 2000 SP4 (and IPv6 patch, by the way). Those make the example work. However, an graphical application such as pan built on top of it is very sluggish (contrary to its linux equivalent). I don't know if it is the 'Sleep(10)' in the patch or the way the application uses sockets. I also tested glib 2.7.3 CVS in spite of any binary incompatibility. The build process has been quite painful, but the test example works. However, pan doesn't work right, but that could have been expected, I guess.
What Sleep(10)? GLib 2.7.* (and 2.8.* eventually) should be binary compatible with all the older 2.* versions. What makes you think otherwise?
Created attachment 49805 [details] Test case for W2K Make use of standard (IPv4) W2K functions
(I wasn't logged - this text wasn't saved, but fortunately I anticipated the problem) The Sleep(10) I'm referring to is the one that appeared in g_io_win32_finalize() in this patch: http://bugzilla.gnome.org/attachment.cgi?id=47495&action=view Comment says that it waits for select_thread(). I don't know when all of this is used and how it modifies a program's behaviour. I have tried several values, but it doesn't seem to affect the freeze duration (untill the application redraws/paints) Sorry for not having being clear with this "in spite of any binary incompatibility". I meant by this that I was trying even if I didn't know if there was some uncompatibility - making the test useless. 2.6 has been binary compatible with 2.6, I didn't know how much 2.7 was to 2.4. Nothing made me thing otherwise, except that 2.(even) sounds to me like "experimental", "time for changes and break things". I've attached a modified test case that should compile out-of-the-box on Windows 2000. The proposed test case uses IPv6 functions unavailable to most versions of Windows 2000, including SP4. I'm not really familliar with network programming so there may be some unwanted/unexpected behaviours.
Well, that patch that contained the Sleep() didn't get in. The socket code in giowin32.c is totally rewritten in HEAD (i.e., what will be GLib 2.8). There are no longer any separate threads for watched GIOChannels for sockets, for instance. Your test case works as expected with HEAD Glib.
I only managed to compile glib.dll from CVS this time, but both the test case and the application 'pan' run fine. The later, which was experiencing major stuttering, no longer suffer from those stutters. But somehow, after some time, a 'pan' task stops receiving data for no reason, as the 2.6.5 dll allows the exact same task to complete fine. I'll try to backport the giowin32.c socket code to 2.6.5 to see how it behaves.
giowin32.c CVS compiles fine within glib 2.6.5 However, the program has the same problem. If I manage to track down where this happens, I'll try to fill in another bug.