|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] [PATCH v2 2/2] vnc: threaded VNC server |
Date: | Sun, 06 Jun 2010 17:53:35 +0300 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4 |
On 06/06/2010 05:48 PM, Corentin Chary wrote:
On Sun, Jun 6, 2010 at 4:11 PM, Avi Kivity<address@hidden> wrote:On 06/04/2010 04:20 PM, Corentin Chary wrote:+ if (vnc_trylock_display(vd)) { + vd->timer_interval = VNC_REFRESH_INTERVAL_BASE; + qemu_mod_timer(vd->timer, qemu_get_clock(rt_clock) + + vd->timer_interval); + return; + } + has_dirty = vnc_refresh_server_surface(vd); + vnc_unlock_display(vd);This could delay the update by quite a bit, no?Yep, but it's far better than waiting the lock because it doesn't slow down the main thread. I played big buck bunny trailler (33sec) in mplayer and tight encoding: - ~40 sec with the non-threaded server - ~37 sec with a lock - ~33 sec with a try_lock
Definitely, blocking the main thread is a no-no.
A more elaborate approach would be to enqueue the refresh job into the queue. May need the iothread enabled so we have qemu_mutex.Maybe, but I'd like to wait the generic async work subsystem before adding different kind of jobs to the queue. And it's already a big improvment over the current code :).
Hm, ok.
btw, I could not find other uses of vd->mutex, shouldn't it protect against the work thread?Check vnc-jobs.c, there is a qemu_mutex_lock(vs->vd->mutex);
Shouldn't it use vnc_lock_display()? That's why I missed it. -- error compiling committee.c: too many arguments to function
[Prev in Thread] | Current Thread | [Next in Thread] |