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>
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>
During every iteration of the main worker loop, outgoing data was pushed to
the client. However, there was no guarantee that the loop would be woken up
in every situation. So there were some conditions where the loop would stop
iterating until a new event was sent.
Currently, the events that can wake up the main worker loop include:
- data from dispatcher (including wakeups from the guest)
- data from clients
- timeouts on a stream
- other timeouts
- polling
This patch adds a new wakeup event: when we have items that are queued to
be sent to a client, we set up a watch event for writing data to the
client. If no items are waiting to be sent, this watch will be disabled.
This allows us to remove the explicit push from the main worker loop.
This has some advantages:
- it could lower latency as we don't have to wait for a polling timeout.
From my experiments using a tight loop (so not really the ideal
condition to see the improvements) the total time was reduced by 2-3%)
- helps reduce the possibility of hanging loops
- avoids having to scan all clients to detect which one can accept data.
Signed-by: Frediano Ziglio <figlio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Use the glib mainloop instead of writing our own. The glib loop is both
cleaner to use and is more extensible. It is also very mature and
reduces the maintenance burden on the spice server.
Signed-off-by: Marc-André Lureau <marcandre.lureau@gmail.com>
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
red_channel_max_pipe_size returns 0 if no client (channel disconnected)
no need to check if cursor_channel/display_channel are NULL or
connected.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma at redhat.com>
Calling cursor_channel_disconnect does not free cursor_display
so this causes a leak.
Is the only code where this pointer is reset preventing any
further cursor channel connection. If a client is lazy reading
cursor data during the flush connection is closed and further clients
won't be able to use the cursor.
This also prevents future use of a NULL pointer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma at redhat.com>
This increase code reuse and make Glib integration more straight forward.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This is mainly question of style.
Instead of repeating same conversion use the variable we set at the
beginning of the function.
Note also that I used same name to make the two functions more
similar.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
All checks for full channel pipes have to be consistents
so there is no point in passing as a parameter.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
spice_warn_if_fail() is doing the same thing except for the inverted
condition. spice_warn_if() is being removed from spice-common to avoid
having potentially confusing redundancy.
Now we can use the iface parameter to distinguish the context instead
of doing strange assumption on opaque and its state.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This patch and previous ones want to solve the problem of not having a
context in SpiceCoreInterface. SpiceCoreInterface defines a set of
callbacks to handle events in spice-server. These callbacks allow to
handle timers, watch for file descriptors and send channel events.
All these callbacks do not accept a context (usually in C passed as a
void* parameter) so it is hard for them to differentiate the interface
specified.
Unfortunately this structure is used even internally from different
contexts for instance every RedWorker thread has a different context. To
solve this issue some workarounds are used. Currently for timers a variable
depending on the current thread is used while for watches the opaque
parameter to pass to the event callback is used as it currently points just
to RedChannelClient structure. This however imposes some implicit
maintainance problem in the future. What happens for instance if for some
reason a timer is registered during worker initialization, run in another
thread? What if we decide to register a file descriptor callback for
something not a RedChannelClient? Could be that the program will run
without any issue till some bytes change and weird things could happen.
The implementation of this solution is done implementing an internal "core"
interface that has context specific and use it to differentiate the
context instead of relying on some other, hard to maintain, detail. Then an
adapter structure (name inpired to the adapter pattern) will provide the
internal core interface using the external, public, definition (in the
future this technique can be used to extend the external interface without
breaking the ABI).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Define an internal structure that matches 100% the ABI of the public one.
The structure will be changed by following patches.
See comments in "channel: add interface parameters to
SpiceCoreInterfaceInternal" patch.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Use CLOCK_THREAD_CPUTIME_ID instead of getting the clock
with pthread_getcpuclockid.
This avoids to call red_worker_get_clockid. This function returns
uninitialized value at the time DisplayChannel is built resulting in setting
statistics to CLOCK_REALTIME (which is 0) instead to cpu time as expected.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
They clarify the time unit being used, reduce the need for casts and
simplify calculations.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Given that it is used for both cursor and display, COMMON_CLIENT_TIMEOUT
seems more appropriate. Also define it only in red-worker.h.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is a generic function not tied to the red_xxx functionality and the
new name clarifies that it returns the time in nanoseconds (unlike
g_get_monotonic_time()).
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
If surface_id is not valid we should still release resource allocated
by red_get_update_cmd and from the guest.
This to reduce leaks in case of a race or another error in the guest
driver.
Also not issue a warning on invalid surface number to avoid filling
log space unconditionally.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
