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 polls/selects/does-some-platform-equivalent-of-wait-for-something.
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! - http://arc.pasp.de/
Attachment:
0x6759BA74.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature