[Spice-devel] [PATCH 8/9] worker: make sure we dispatch after releasing items

Marc-André Lureau mlureau at redhat.com
Thu Dec 17 15:34:35 PST 2015


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.


More information about the Spice-devel mailing list