| Age | Commit message (Collapse) | Author |
|---|
|
QEMU now has a fundamental requirement for pthreads, so there
is no compelling reason to retain support for the non-threaded
VNC server. Remove the --{enable,disable}-vnc-thread configure
arguments, and all CONFIG_VNC_THREAD conditionals
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
The threaded VNC servers messed up with QEMU fd handlers without
any kind of locking, and that can cause some nasty race conditions.
Using qemu_mutex_lock_iothread() won't work because vnc_dpy_cpy(),
which will wait for the current job queue to finish, can be called with
the iothread lock held.
Instead, we now store the data in a temporary buffer, and use a bottom
half to notify the main thread that new data is available.
vnc_[un]lock_ouput() is still needed to access VncState members like
abort, csock or jobs_buffer.
Signed-off-by: Corentin Chary <corentin.chary@gmail.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
|
Implement a threaded VNC server using the producer-consumer model.
The main thread will push encoding jobs (a list a rectangles to update)
in a queue, and the VNC worker thread will consume that queue and send
framebuffer updates to the output buffer.
The threaded VNC server can be enabled with ./configure --enable-vnc-thread.
If you don't want it, just use ./configure --disable-vnc-thread and a syncrhonous
queue of job will be used (which as exactly the same behavior as the old queue).
If you disable the VNC thread, all thread related code will not be built and there will
be no overhead.
Signed-off-by: Corentin Chary <corentincj@iksaif.net>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
|
