The patch attached to bug #357674 didn't help for this problem after all. Will have to read through that bug description and the patch closely and commit if I am reasonably convinced it doesn't cause any regressions...
Anyway, it turns out that at least on Linux poll() sets POLLERR|POLLHUP when it returns after polling a socket that is being asynchronously connected and the connection finally has failed. So g_io_win32_check() in giowin32.c should also set G_IO_ERR and G_IO_HUP in this case. I read in http://www.opengroup.org/onlinepubs/000095399/functions/poll.html that POLLOUT and POLLHUP are mutually exclusive. I guess this means GLib should also guarantee that G_IO_OUT and G_IO_HUP are mutually exclusive. But on the other hand, if I understand the documentaion correctly, Win32 signals FD_CLOSE only once, so do we need to make that "sticky" once received once? Sigh... Anyway, I committed a patch to giowin32.c that makes your test program's callback function receive G_IO_ERR when the connect() fails. (After that the program goes into a tight loop and keeps doing g_main_poll() even if there is nothing to poll...) 2007-07-06 Tor Lillqvist <[EMAIL PROTECTED]> * glib/giowin32.c (g_io_win32_check): When WSAEnumNetworkEvents() signals FD_CONNECT that means that the connection attempt finished, either successfully or failed. Test explicitly whether the connnection succeeded and set either G_IO_OUT if it did, G_IO_ERR|G_IO_HUP if it failed. Make sure we never set both G_IO_OUT and G_IO_HUP simultaneously because in Unix poll(2) POLLOUT and POLLHUP are mutually exclusive. Ignore whether the caller wants to watch G_IO_HUP or not. Always select for FD_CLOSE because Unix poll(2) also ignores whether POLLHUP in set the requested events bitmask or not. --tml _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
