On Mon, Dec 30, 2019 at 06:21:27PM +0000, Eltahawy, Mahmoud wrote: > I am new to QEMU and I am using qemu-3.0.1, I noticed a strange behavior for > qemu_set_fd_handler that the callback for reading from a file descriptor is > delayed then expected while the file descriptor(socket) has a data to read. > > I register a callback for reading from a socket using qemu_set_fd_handler and > during runtime, this callback is not invoked for about 14msec, however the > socket has a data available for read. I tested this behavior by just creating > a pthread which periodically checks the socket for any data using > ioctl(socket_fd, FIONREAD, &count), and for a period of 14ms, I found that > the pthread indicates there is a data in the socket while the > qemu_set_fd_handler didn't trigger the read callback.
QEMU uses an event loop. If another handler takes 14 ms to execute, then the fd handler could be delayed. Is there other event loop activity? Also, a polling thread will respond more quickly than the event loop because the event loop thread is waiting for the host kernel scheduler to wake it up. When the host is under heavy load this could take some time, depending on the scheduler and its settings. Was the machine under heavy CPU load? Stefan
signature.asc
Description: PGP signature
