> > > I don't think this works well enough: if the source isn't removed, but
> fd_can_read() returns 0, there is a potential busy loop on the next > > fd_read(). > This shouldn't happen. The sources all get set to non-blocking mode, the only blocking code is the poll itself. If fd_can_read() returns 0, then the next time fd_read() is called, it will attempt to read zero bytes. The backend logic checks the results of the same method that fd_can_read() calls and sets its read size to that amount, in the case of a full buffer it will read 0 bytes and return. > My understanding is that if data is read from the frontend, the loop > > will be re-entered and io_watch_poll_prepare will set the callback > > again. > This just doesn't happen. The issue is that between the poll being added (and some but not all data being read) and the frontend code getting triggered by the guest, the IO loop runs again and the poll is removed, it then runs again with the poll removed (since the poll is removed during setup) and it's now just going to block because the input fd in question has been "temporarily removed". Except that nothing in the fd set it polls on is now connected to the guest clearing the buffer. Meanwhile the guest reads the data during what can be a potentially infinite block (if nothing else sets the timeout, in my case something in the uart peripheral sets a 1000ms timeout so I could read a byte every second or so in the guest). The guest will now be spinning until the poll is re-added, meanwhile the poll is blocking on a timeout or another fd becoming ready because the buffers are small, the fd in question has already been removed from the set by the time the guest has a chance to clear the buffer. > > Could you provide a simple use-case or reproducer where we can > > evaluate how your patch improves the situation? I can do this, but I don't have anything ready immediately, my test case isn't ideal for others to reproduce. But I can attach one later today when I have that done. Thanks, Iris Johnson
