[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