Il 21/02/2013 17:29, Jan Kiszka ha scritto: > In this context, I'd like to recall a detail: Real-time prioritization > of those I/O threads will most probably require locking with > prio-inversion avoidance (*). In that case external libs without a > chance to tune or replace their internal locking (like glib) will be a > no-go for those kind of I/O threads. > > The glib mainloop might be fine for all the rest, but we will likely > also need event loops with RT-compatible locking. So this refactoring > should keep the door open for alternative implementations.
Yes, this refactoring is fine. It doesn't use the glib mainloop any more than before. AioContext is fine as an RT-compatible event loop. You can use both as a GSource or manually from a separate thread. What would be more problematic is the chardev flow control patches, which use the glib main loop directly. I don't recall your KVM forum presentation---did you need RT prioritization of the serial port too? Paolo > Jan > > (*) Scenario: RT-iothread with highest prio wants to take a lock that is > held briefly by low-prio maintenance thread which is interrupted by > long-running medium-prio VCPU thread. This can delay or prevent the > event injection. Of course, this depends on the existence of such > dependencies.