Il 05/03/2012 10:07, Jan Kiszka ha scritto: > > This is quite ugly. Two threads, one running main_loop_wait and > > one running qemu_aio_wait, can race with each other on running the > > same iohandler. The result is that an iohandler could run while the > > underlying socket is not readable or writable, with possibly ill effects. > > Hmm, isn't it a problem already that a socket is polled by two threads > at the same time? Can't that be avoided?
We still have synchronous I/O in the device models. That's the root cause of the bug, I suppose. > Long-term, I'd like to cut out certain file descriptors from the main > loop and process them completely in separate threads (for separate > locking, prioritization etc.). Dunno how NBD works, but maybe it should > be reworked like this already. Me too, I even made a very simple proof of concept a couple of weeks ago (search for a thread "switching the block layer from coroutines to threads"). It worked, though it is obviously not upstreamable in any way. In that world order EventNotifiers would replace qemu_aio_set_fd_handler, and socket-based protocols such as NBD would run with blocking I/O in their own thread. In addition to one thread per I/O request (from a thread pool), there would be one arbiter thread that reads replies and dispatches them to the appropriate I/O request thread. The arbiter thread replaces the read callback in qemu_aio_set_fd_handler. The problem is, even though it worked, making this thread-safe is another story. I suspect that in practice it is very difficult to do without resurrecting RCU patches. Paolo
