Hi ----- Original Message ----- > On Wed, 2015-12-16 at 18:16 -0500, Marc-André Lureau wrote: > > Hi > > > > ----- Original Message ----- > > I actually think that was it. The worker thread may currently block because > > the client is too slow. But then, when we release item, the pipe is going > > to > > be smaller hopefully, and thus we can try to dispatch again without waiting > > for the timeout. (waiting for timers can really degrade performances in > > some > > cases, like you see today with the qemu virgl timer, but that's another > > story where I can show you figures when we merge gl scanounts in spice ;) > > Then I'm still confused. In the old loop, we had a very explicit sequence of > behavior. For each loop: > > 1 calculate timeout for poll() function > 2 poll() fds with timeout from step 1 > 3 service expired timers > 4 handle fd watch events > 5 process cursor commands from guest > 6 process display commands from guest > 7 push queued messages to clients > 8 GOTO 1 > > After pushing the queued messages to the client, we did not go back and > handle > cursor and display commands again. We went back to the top of the loop and > did a > poll with timeout again. So I fail to see why the glib loop needs to short > -circuit the timeout and return to step 5 when the old design didn't. > > Or is this change unrelated to the new glib loop and the worker has simply > always been too slow even with the old loop implementation? > I wouldn't say "too slow", and I wouldn't try to mimic the old code either. For me the goal is simply to process the pipe/command as fast as possible and if possible, get rid of timeouts. _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel