On 11/16/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote: > See the patch below that clears up some of the issues: 1) After > getting FD_CLOSE, make the knowledge of that "stick" and always set > G_IO_HUP. 2) Plug a handle leak, WSACloseEvent the socket's event when > the channel is closed. > > If you can build GLib yourself, please try it.
I can build enough of GLib to try it out. libglib-2.0-0.dll gets built, but when it moves on to build gobject, it hangs up while running glib-genmarshal. If I look at the task manager, ntvdm.exe is using a lot of CPU - why would glib-genmarshal be using the 16-bit VM? Killing ntvdm.exe resumes the build process (but, of course, it fails soon after because the header wasn't generated). Any ideas why glib-genmarshal would be messed up? I'm using the MinGW "Candidate" gcc-3.4.4 and binutils-2.16.91-20050827-1, maybe I should move back to the "Current" versions. Anyway, back to the original issue. The extraneous WSAEnumNetworkEvents() have cleared up :). Unfortunately the patch doesn't seem to have magically fixed my problems. I'm continuing to experience random disconnection issues due to the program getting different data than it expects (these issues are certainly not present with glib 2.6.x). I'm not sure how best to proceed on further debugging. Since I incorporated the fixes you suggested into the gaim_url_fetch() code, it is working great so I don't have a simple test program. I guess I'll have to come up with something. Sorry that I'm so slow to respond. -Daniel
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
