Hot questions for Using Cap'n Proto in event loop
I have a Cap'n Proto RPC server that runs some OpenGL commands in a window. I am not interested in the window's events at all, but in order to avoid getting killed on Windows I need to poll events once a second or so. How can I do this in a simple fashion?
I have read that you can make your own EventPort, but I couldn't figure out how to actually use EventPorts. It might also be overkill when I'm not actually interested in the events. I would like prioritize RPC events over polling the window if possible.
Using something else than EZ-rpc is not a downside, as I want to move to shared memory communication later on.
So, there's this critical flaw in Windows event handling: The best way to handle network I/O, especially with many connections, is via I/O Completion Ports (IOCP). However, unfortunately, Windows provides no way for a thread to wait on IOCP events and GUI events in the same thread. This seems to be a serious design flaw in the Win32 API, yet it's been this way for decades. Weirder still, the internal NT kernel APIs do in fact support an alternative (specifically, they allow I/O completion events to be delivered via APC) but Microsoft hasn't made these APIs public, so applications that use them could break in a future version of Windows.
As a result, there are essentially two ways to design a program that simultaneously does network I/O and implements a GUI:
MsgWaitForMultipleObjectsEx-based event loop instead of IOCP. You will be limited to no more than 64 connections, and the event loop will be relatively inefficient.
Have separate threads for network and GUI.
For your use case, it sounds like #1 would probably be fine, but there's another problem: The KJ event loop library (used by Cap'n Proto) doesn't implement this case yet. It only implements IOCP-based networking. There's a class
Win32WaitObjectThreadPool defined in
kj/async-win32.h meant to handle the GUI event loop approach... but at present it is not implemented. (PRs are welcome if you'd like to contribute!)
If you truly don't care about handling GUI events in a timely fashion, then perhaps a hack would work: You could use
kj::Timer to create a loop that waits for a second, then checks the Win32 GUI event queue, then waits again, and so on. This is really ugly but would probably be easy to implement. I'm not sure if
kj::Timer is exposed via EZ-rpc, so you may have to go to lower-level building blocks like