It's only used in a few debug printfs. If we want these stats, we'll
have to find a better way than forcing a dependency on a high-level
class in a lower-level _unref method just to maintain the stats.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Was causing sporadic crashes.
Also cause compatibility problems with RHEL 6.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Check that cancelling a timer the timer callback is not called.
This can happen in latency code (red-channel.c).
In red_channel_client_cancel_ping_timer latency timer is cancelled and
state is set to PING_STATE_NONE however if timer was already active what
happens is that the red_channel_client_ping_timer is called and the line
spice_assert(rcc->latency_monitor.state == PING_STATE_TIMER);
is triggered causing spice-server to abort.
This happens as GLib loop add all active sources to an array but if the
timer is deactivated before the event is dispatched the event will be
dispatched unless the source is destroyed.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Add RedsState arg to main_channel_new(), and use the 'reds' property
that is stored in the base RedChannel struct rather than the global
'reds' variable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These automatic variable are used just inside the function.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
CommonChannel does not need to know about RedWorker.
This reduce a bit dependencies between objects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The only usage of this ring was to have a message when there was no
commands on the list.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Add a new 'state' property to VDIReadBuf so that we can refer back to
the VDIPortState struct from the readbuf functions.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Store a reference to the server in the SpiceCharDeviceState struct and
use that rather than the global 'reds' variable
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This allows us to use local 'reds' variables in all of the various async
callbacks rather than using the global 'reds' variable.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Rather than relying on a global 'reds' variable, we can pass the needed
instance through the callback user data.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Commit 3a66b75 changed reds_accept_ssl_connection() to expect a RedState
instance when its called, but the core->watch_add() which is calling it
was not changed accordingly. This causes a crash when connecting through
SSL.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
When a client is done with drawing and sends
SPICE_MSGC_DISPLAY_GL_DRAW_DONE, or when it ends, update the number of
async counts.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[reduce critical message to a warning; do not reset gl_draw_ongoing
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Create an async, and marshall the GL_DRAW message. Count number of
clients, and wait until gl_draw_async_count is 0 to complete the async.
The count is going to be updated in the following patch when the client
is done with the draw.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[removed unused sent field; move gl_draw_async_count to DisplayChannel
- Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Go through dispatcher and marshall scanout message. Since the marshaller
and the QXL state are manipulated from different threads, add a mutex to
protect the current scanout.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
- spice_qxl_gl_scanout() to take the current scanout
- spice_qxl_gl_draw_async() to draw the scanout, is like other Spice async
functions, it takes a cookie and will return in the
QXLInterface.async_complete()
Two new fields are also added to QXLState, in order to save the current
scanout, and the pending async.
A scanout can't be updated if there are pending draw atm. Discarding
outdated draws is left as a future improvement to allow updating the
scanout without waiting for draw async to be done.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
[make QXL function names more coherent - Frediano Ziglio]
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Instead of using CPU time use a timer depending on real times.
Currently that time in the record log is not used.
However if we want to reproduce problems with stream would be useful
to have real times instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Now that processing is correctly restored there is no need to keep
polling to avoid main loop hangs. Reduce the polling count to 1
(just try once).
This reduce cpu usage if guests are mainly idle.
If you consider 100 guests waiting to login with cursor blinking
and considering the polling was done 200 times every 10ms (maximum)
just the cursor blinking was causing 10100 loop iterations per second
while now only 200 are needed (considering cursor blinking every
second).
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Make sure we process commands after we can send data to client.
If during processing we detected that there was too much data in the
clients queues the processing of commands just stop till the next
iteration.
However if all data are pushed in a single iteration of the loop
and commands were already processed there was the (remote) possibility
that the loop hangs till a separate event (like a screen resize on
client window) arrive.
I manage to reproduce and after half an hour no events arrived.
This patch detect that processing was stuck and now we can process new
commands and force a new iteration.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
The req_cmd_notification callback is called by spice-server when it
has processed all commands and wants to be notified (by a wakeup) that
new commands have been appended to the command queue.
Replay utility tries to fill the commands when it detects that
spice-server is trying to read commands but there are no more commands.
However, new commands are appended in a separate thread so if the main
red worker loop on spice-server is really tight this request can
happen.
Avoid printing any message on this condition, message will be appended
and loop woken up when replay code can do it.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
