Can I wait for GUI events — that is, pump a message loop — and on an I/O completion port at the same time? I would like to integrate libuv with the Windows GUI.
-
not exist api call which let you at once wait for I/O completion port and GUI events. you need how minimum 2 separate threads for this – RbMm Jan 15 '18 at 10:36
-
@RbMm can it be done with the undocumented Native API? – Demi Jan 16 '18 at 04:52
-
even with undocumented Native API - no. and by sense - on iocp usually wait thread pool, gui thread have separate tasks. for what you need use only single thread for iocp and combine it with gui ? – RbMm Jan 16 '18 at 07:08
-
@RbMm Using Node.js or similar in a GUI. I cannot run JS code on any thread but the main thread. – Demi Jan 16 '18 at 16:26
1 Answers
There are two solutions that I know of. One works on all versions of Windows, but involves multiple threads. The other is faster, but only supports Windows 10+ (thank you @RbMm for this fact).
Another thread calls
GetQueuedCompletionStatusEx
in a loop, and sends messages to the main thread withSendMessage
. The main thread reads the messages from it's message loop, notes the custom message type, and dispatches the I/O completions.This solution works on all versions of Windows, but is slower. However, if one is willing to trade latency for throughput, one can increase the
GetQueuedCompletionStatusEx
receive buffer to recover nearly the same throughput as the second solution. For best performance, both threads should use the same CPU, to avoid playing cache ping-pong with the I/O completions.The main thread uses
MsgWaitForMultipleObjectsEx
to wait for the completion port to be signaled or user input to arrive. Once it is signaled, the main thread callsGetQueuedCompletionStatusEx
with a zero timeout.This assumes that an IOCP that is used by only one thread becomes signaled precisely when an I/O completion arrives. This is only true on Windows 10 and up. Otherwise, you will busyloop, since the IOCP will always be signaled. On systems that support this method, it should be faster, since it reduces scheduling overhead.
-
1unfortunately 2 will be work only begin from win 10. in all previous windows versions any wait on iocp just return 0 (object is signaled) regardless of real state of iocp. this is because system wait not on your iocp itself but on common *default object* for iocp type. – RbMm Jan 27 '18 at 00:54
-
-
begin from win10 system wait on iocp itself and this begin work. on yet win8.1 system wait on common default object for iocp type – RbMm Jan 27 '18 at 01:41