After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 309241 - GIOChannel doesn't signal that a socket is ready to write
GIOChannel doesn't signal that a socket is ready to write
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: win32
2.6.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-win32 maintainers
Depends on:
Blocks:
 
 
Reported: 2005-07-01 04:29 UTC by Kenneth Haley
Modified: 2005-07-31 00:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test-case (4.02 KB, text/plain)
2005-07-01 04:33 UTC, Kenneth Haley
Details
Test case for W2K (4.43 KB, text/plain)
2005-07-26 21:32 UTC, Christophe GISQUET
Details

Description Kenneth Haley 2005-07-01 04:29:25 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.
Comment 1 Kenneth Haley 2005-07-01 04:33:33 UTC
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
Comment 2 Christophe GISQUET 2005-07-10 03:25:13 UTC
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.
Comment 3 Christophe GISQUET 2005-07-10 14:54:15 UTC
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.
Comment 4 Tor Lillqvist 2005-07-14 17:17:16 UTC
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?
Comment 5 Christophe GISQUET 2005-07-26 21:32:30 UTC
Created attachment 49805 [details]
Test case for W2K

Make use of standard (IPv4) W2K functions
Comment 6 Christophe GISQUET 2005-07-26 21:33:33 UTC
(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.
Comment 7 Tor Lillqvist 2005-07-27 08:51:35 UTC
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.
Comment 8 Christophe GISQUET 2005-07-30 23:47:31 UTC
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.
Comment 9 Christophe GISQUET 2005-07-31 00:03:50 UTC
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.