This should always be defined and including config.h is a requirement.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
New functions and macros have been added in glib 2.38 to better handle
this case.
c8de2b11bb/NEWS
G_TYPE_INSTANCE_GET_PRIVATE will be deprecated in GLib 2.58.
https://gitlab.gnome.org/GNOME/glib/merge_requests/7/commits
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is a preparatory patch for next portability patches
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The remaining occurrences of spice_printerr() are warnings when
something unexpected happens, they can be replaced with g_warning() so
that users of spice-server can redirect them with
g_log_set_default_handler().
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Depending on the context, we want to output a warning or just a debug
log.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
These calls seem to have been added for debugging for a very specific
purpose. At the very least, they should have been using g_debug() rather
than spice_printerr(). This commit removes these.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This array is just used locally in red_channel_client_handle_outgoing
so declare it there.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
In order to use the new TCP_CORK feature, disable auto flush.
Depending on channel implementation and purpose of the channel enabling
blindly for all channels could cause performance issues, specifically if
flush is not done at the right time.
CommonGraphicsChannel channels were tested to make sure is not that case.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
The name is more consistent with the value of the flag and
the function red_channel_client_wait_pipe_item_sent where
the MarkerPipeItem structure is used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Currently, red_channel_client_wait_pipe_item_sent() inserts a MarkerItem
which will sent after the item we want to wait for: the tail of the
queue is the first item to send, and the function uses
red_channel_client_pipe_add_after_pos(). Then, if the marker has been
successfully sent, the function calls
red_channel_client_wait_outgoing_item to wait for 'item' to be sent.
Instead of doing this, we can add the MarkerItem to the queue so that
it's sent after 'item' (ie, insert it _before_ 'item' in the queue).
This way, when the marker is marked as having been sent, we'll also know
that 'item' has been sent.
This avoids having to call red_channel_client_wait_outgoing_item and
possibly the case where the item was not queued and
red_channel_client_wait_outgoing_item returning TRUE even if the item
was not sent as required.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Avoid repeating the same code twice.
red_channel_client_send sends the pending item (or a part of it). If
there are no item pending, the function does nothing (so checking for
blocked channel is useless). Also red_channel_client_send is already
called from red_channel_client_push which has a check for blocked
channels, so having calls to both red_channel_client_send() and
red_channel_client_push() is redundant.
The function on its overall tries to wait for a given item to be sent.
The call for red_channel_client_receive is mainly needed to support the
cases were to send data messages from the client should be processed
(like if "handle-acks" is requested).
Moving the loop iteration check inside the for loop instead allows to
avoid some duplication.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Instead of having MarkerPipeItem pointing to an external variable with
the possibility to forget to reset it and have a dangling pointer, this
commit takes a reference on the item to keep it alive after it was sent.
This item is placed into the queue to understand when it was sent. The
current implementation detects the unqueue when the item is destroyed so
we currently store a pointer to an external variable in the item, this
way we can use a variable which will still be alive after the item is
released/destroyed.
This change updates the variable (stored in the item) when we try to
send the item, rather than at destruction time. The destruction happened
at the end of red_channel_client_send_item(), so we don't mark
item_in_pipe much earlier than before.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This commit adds red_channel_{debug,warning,printerr}() helpers which
will prepend the log message with "channel-name:id (%p)". It also
changes various locations which were doing this manually.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The objects RedsStream and RedsSASL are currently using the namespace
"Reds" rather than the standard "Red" namespace used throughout the rest
of the project. Change these to be consistent. This also means changing
method names and some related enumeration types.
The files were also renamed to reflect the change:
reds-stream.[ch] -> red-stream.[ch]
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since commit ef4b1bdb "red-channel-client: Prevent too tight loop
waiting for ACKs", after seamless migration, the display is no longer
updated on the client-side, even though the VM is functional (responds
to keyboard input, reconnecting the client restores the display
functionality, ...).
This is mainly caused because after migration,
red_channel_client_waiting_for_ack() will be true until
red_channel_client_ack_zero_messages_window() is called.
What happens is the following:
The dcc is created, and dcc_start() pushes a RED_PIPE_ITEM_TYPE_SET_ACK
message.
This calls prepare_pipe_add(), which will enable write event on the dcc
watch. red_channel_client_event() will be called, which will trigger a
red_channel_client_push(). Since red_channel_client_waiting_for_ack()
returns true, we won't get any item to push, and (because of commit
ef4b1bdb), we will disable write notifications on the watch.
At this point, rcc->priv->pipe is no longer empty, so prepare_pipe_add()
is not going to reenable the write notifications.
Then red_channel_client_ack_zero_messages_window() is finally called as
part of dcc_handle_migrate_data(), so from this point on,
red_channel_client_waiting_for_ack() is no longer true.
However, nothing ever reenables WRITE events, nor empties
rcc->priv->pipe, so nothing ever gets pushed, causing no display updates
at all after a migration, even if the VM is functional (input, ...)
apart from that.
This commit reenables WRITE events in
red_channel_client_ack_zero_messages_window() if we were waiting for
ack.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
RedChannelClient has a "handle-acks" feature.
If this feature is enabled, after the configured number of messages it
waits for an ACK from the client.
If is waiting for an ACK it stops sending messages.
However the write notification was not disabled, causing the loop event
to always trigger, as the socket in this case is ready to accept data.
Specifically red_channel_client_event is continuously called.
This is noticeable using slow network environments and having
some additional loop instrumentation.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Now the push is done automatically when a PipeItem is added
(cfr commit 5c460de1a3
"worker: push data when clients can receive them"),
forcing a push cause only network fragmentation and is required only if
you are handling data in a polling loop (and thus, you are preventing
the default event loop from running).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
There is exactly one user in RedChannel, and this can be reimplemented
using already public RedChannelClient API. No need for an extra
function very specialized function with a not great name.
This commit thus removes one method from RedChannelClient public API,
and replaces it with an equivalent private helper in RedChannel.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The code tests for the presence of RedChannelClient::stream while
initializing RedChannelClient.
However, the check was done too late, and a
RedChannelClient::config_socket implementation (for example
snd_channel_client_config_socket) could have tried to use it before the
check that it's not NULL.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This field was used only by RedChannelClient to mark when the socket
was shutdown. This condition can simply be tested by RedChannelClient
checking if there's a watch as is the only condition (beside object
destroying/disconnecting) where the watch is removed.
In any case the shutdown was used to understand if there were possible
data still to read.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
You could easily trigger this issue using multiple monitors and a
modified spice-gtk client with this patch:
--- a/src/channel-main.c
+++ b/src/channel-main.c
@@ -1699,6 +1699,7 @@ static gboolean _channel_new(channel_new_t *c)
{
g_return_val_if_fail(c != NULL, FALSE);
+ if (c->type == SPICE_CHANNEL_DISPLAY) c->id = 0;
spice_channel_new(c->session, c->type, c->id);
g_object_unref(c->session);
which cause a crash like
(process:28742): Spice-WARNING **: Failed to create channel client: Client 0x40246f5d0: duplicate channel type 2 id 0
2017-08-24 09:36:57.451+0000: shutting down, reason=crashed
RedChannelClient is an GInitable type, which means that the object is
constructed, and then the _init() function is called, which can fail.
If the _init() fails, the newly-created object will be destroyed. As
part of _init(), we add a new watch for the stream using the core
interface that is associated with the channel. After adding the watch,
our rcc creation fails (due to duplicate ID), and the rcc object is
unreffed. This results in a call to reds_stream_free() (since the rcc
now owns the stream). But in reds_stream_free, we were trying to remove
the watch from the core interface associated with the RedsState. For
most channels, these two core interfaces are equivalent. But for the
Display and Cursor channels, it is the core Glib-based interface
associated with the RedWorker.
The watch in RedsStream by default is bound to the Qemu provided
SpiceCoreInterface while RedChannelClient bound it to Glib one causing
the crash when the watch is deleted from RedsStream. Change the bound
interface.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Implements red_channel_pipes_add_type and
red_channel_pipes_add_empty_msg using red_channel_pipes_add.
This avoid duplicating items for each client.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Now the push is done automatically when a PipeItem is added
(cfr commit 5c460de1a3
"worker: push data when clients can receive them"),
forcing a push cause only network fragmentation and is required only if
you are handling data in a polling loop (and thus, you are preventing
the default event loop from running).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
SoundChannelClient has a stub implementation of
RedChannelClient::on_disconnect(), this commit removes the need for it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This vfunc only has a RedChannelClient * argument, and most of the time,
it operates on RedChannelClient, not on RedChannel. Moreover, the only
time it's used is from RedChannelClient. This commit moves the vfunc to
RedChannelClient, which seems like a better fit for it.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Some RedChannelClient data members were marked as int when they only
hold booleans.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This is causing issues with potential improvements to the logging
system, and I've always found this usage a bit odd anyway.
Using spice_debug(""); was not possible as this triggers
-Wformat-zero-length warnings from our use of -Wall.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
red_channel_client_clear_sent_item() will clear send_data.blocked, so no
need to do it in red_channel_client_msg_sent() as well.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Now that red_channel_client_set_blocked() is no longer changing the
events we are watching for, we can call it from
red_channel_client_push().
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since 5c460d, we need to watch for WATCH_EVENT_WRITE as long as there are
items queued waiting to be sent, this does not need to be done only when
the network queue is full.
When red_channel_client_set_blocked() is called, as a message is being
sent, WATCH_EVENT_WRITE will already be set, so it does not need to set
it again.
red_channel_client_msg_sent() removes WATCH_EVENT_WRITE, but this will
be done later anyway by red_channel_client_push() if needed.
Since it's redundant, we can remove this.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
red_channel_client_msg_sent() calls red_channel_client_clear_sent_item()
which will clear the rcc->priv->send_data.blocked flag. Later on, it
contains a check for !red_channel_client_is_blocked(), which will always
be true as nothing in between could have set it again. This commit
removes this unneeded check.
This check was already redundant when it was introduced in
9a62a9a809
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Before this commit, red_channel_client_start_ping_timer() and
red_channel_client_cancel_ping_timer() had checks to be no-ops when
rcc->priv->latency_monitor.timer is NULL.
This commit adds a similar check to
red_channel_client_restart_ping_timer(), and removes explicit NULL
checks before calls to red_channel_client_{cancel,restart,start}_ping_timer()
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
rcc is just used on the next line so cannot be NULL.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Their uint32_t value is never used, all that matters is whether we
received data or not.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Both _test_remote_cap() and _test_remote_common_cap() are used as
boolean values, so change the return type from int to bool to follow our
coding standard.
This new function removes one place outside of RedsStream which needs to
access RedsStream::socket
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The code to enable/disable on a TCP socket is duplicated in multiple
places in the code base, this commit replaces this duplicated code with
a helper in RedsStream.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This commit changes all functions returning TRUE/FALSE from having an
'int' return value to 'bool'.
This way it's obvious that such a function is not going to return
anything else than TRUE or FALSE.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
config_socket is configuring the client stream socket.
As is responsibility of RedChannelClient to handle the stream
it make more sense to have the function in this object.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
These vfuncs are more appropriate in RedChannelClient.
The buffer they allocated are related to the client stream
which is managed directly by RedChannelClient.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
As the counters are shared there is no reason why not
handling the byte count from RedChannelClient directly.
This remove a dependency and avoid some function calls.
The only visible difference at user level is that the
counters are created when a client connects.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Show messages sent to clients.
This is useful to understand the message number as an high
message number can affects performance and is not easy to
understand the message count from the byte count (which is
available).
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
