When I used to write more networking C code, I used to be careful to write my libraries to be event loop agnostic. And if my library had its own event loop, I made sure that it could be stepped independently so it could sit atop another application event loop. This is alot easier on modern Unix systems because kqueue and epoll can be stacked--you can poll a kqueue/epoll descriptor from another kqueue/epoll descriptor, so sockets, timers, etc registered with the first will bubble up to the parent and your library-specific event loop can just export a single file descriptor to be polled by another event loop.[1] Windows doesn't have such a capability so there's no simple way to bubble events.

Of course, you can run your different event loops in different threads, but then you have to deal with the nightmare of shared data multithreading. Rust makes multi-threading "fearless" because it heavily restricts multiple threads from holding references to the same object, so Rust doesn't help in this regard, especially considering you're integrating with non-Rust code and, worst of all, GUI APIs, which tend to be some of the most inscrutable and hostile code with which to integrate.

[1] This is effectively structured concurrency as a first-class kernel interface, an elegant characteristic of kqueue and epoll that is sorely underappreciated and rarely used.