Re: g_io_add_watch and non-blocking io on windows



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  <tml novell com>

        * 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]