Re: g_io_channel_win32_poll() Problem on Windows

On 7/28/2017 3:08 PM, Paul Davis wrote:

On Fri, Jul 28, 2017 at 4:37 AM, LRN wrote:
After trying this myself (for unrelated reasons), i found that *only*
giochannel GSource does WSAEventSelect() on a socket event (in
g_io_win32_prepare()) to bind it to an event handle, which can then be polled.
If you are not using a main loop (and GSource), then this doesn't happen, and
the events you feed to g_poll() are completely inert.

This is true on all platforms. The "responsiveness" of all GSources depends on
a main loop that

That's not what i meant. On Windows g_poll() is just a glorified
WaitForMultipleObjectsEx() that waits on an array of handles.
The polling of sockets is done in a very circuitous way - and event is bound to
a socket with WSAEventSelect(), then that event is polled, then, once the event
is signaled, the code in W32-socket-based GSource calls WSAEnumNetworkEvents()
to get the socket-level events triggered the signaling.

For blocking I/O (W32 nameless pipes) same thing applies - the events that
g_poll() waits upon are, in fact, special events attached to a separate thread
that does the actual I/O.

g_poll() itself does almost nothing. The revents that it fills in the GPollFD
structs are just copies of the events field (the copying is done when the
corresponding event is signaled).

So, the main takeaway here is that you should either do what GSource+gmainloop
do (source prepare, then g_poll, then source check), or just use GSource+gmainloop.

O< ascii ribbon - stop html email! -

Attachment: 0x6759BA74.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

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