If file was compiled with DEBUG defined code did not compile.
Update code of the surrounded section.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
I've never seen used and Dispatcher is quite a code piece of
code, hard to break it.
I also tried to enable and it does not even compile anymore.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
We just created the object, we know is a RedCharDeviceSmartcard,
avoid to cast the pointer using RED_CHAR_DEVICE_SMARTCARD.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
These structures are not used that extensively, do not include
in the common header.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Not used in the header.
Also we reduced a lot the usage of these structures.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
red_channel_client_destroy is not called anymore from RedClient and
should not so update the comments.
red_channel_client_destroy, compared to other XXX_destroy functions
did not unreference the object but was just disconnecting the
client channel so use red_channel_client_disconnect instead.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The object is already destroyed calling red_channel_disconnect_client.
The difference is that red_channel_disconnect_client does it in
the right thread while red_channel_client_destroy here attempts to
do potentially from another thread. This however at this stage
(after already being disconnected) is not an issue, just redundant
and potentially unsafe if red_channel_client_destroy change in
a way to have issue with multiple threads.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
The field is only set and never checked.
Cascading cleaning up red_channel_client_set_destroying.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
"RedChannelClient::on_disconnect", which for SpiceVMC is bound to
"spicevmc_red_channel_client_on_disconnect", is called while the
RedChannel object is disconnecting. More precisely is called after
the object has been removed from RedChannel causing
"red_channel_client_is_connected" to be false.
Calling "red_channel_client_destroy" this will lead
to a no-op as function will set "destroying" and call
"red_channel_client_disconnect" which will just exit finding
"red_channel_client_is_connected" false.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Minimal style change.
Allows to easier change the size of the buffer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Francesco Giudici <fgiudici@redhat.com>
Minimal style change.
Allows to easier change the size of the buffer.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Francesco Giudici <fgiudici@redhat.com>
Allows to specify abstract Unix sockets addresses.
These Unix sockets are supported on Linux and allows to not
have file system names.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Kevin Pouget <kpouget@redhat.com>
It is not guaranteed that all the messages will be sent on a single
push call, unless this is done very early.
Although currently this function is called very early remove
this hidden assumption in the code.
"ping_id" is just incremented every time a message is sent to
client (in "main_channel_marshall_ping") so the formulae
"mcc->priv->ping_id - 2" was there to get the id of two messages
ago (the first message queued in this function) assuming all
messages were pushed at the time the formulae is used.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Snir Sheriber <ssheribe@redhat.com>
FALSE is the default value, no need to set explicitly.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
Use new common.m4 include file to make easier to integrate
with spice-common repository.
The new include will allow for instance spice-common to
add additional dependencies without changes (or minor) to
spice-server.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Kevin Pouget <kpouget@redhat.com>
main_channel_client_push_ping is never called with mcc NULL.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Snir Sheriber <ssheribe@redhat.com>
Instead of freeing it in both reds_handle_main_link and
reds_handle_other_links free it in reds_handle_link.
This will reduce the chances code is changed adding a leak in some paths.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Julien Rope <jrope@redhat.com>
Instead of freeing manually the field and then detaching from
the structure just detach only if retained.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Due to aliasing using pointers lead to some sub-optimization.
Use local variable and then write them to output to improve performances.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Julien Rope <jrope@redhat.com>
Since 03d46e9e "build-sys: Raise glib requirement to 2.38" in
2019-02-05
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
g_assert_null, g_assert_true and g_assert_false are all defined in
GLib 2.38
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Basically not run since 03d46e9e "build-sys: Raise glib requirement to
2.38" in 2019-02-05
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Not used since 03d46e9e "build-sys: Raise glib requirement to 2.38" in
2019-02-05
Signed-off-by: Victor Toso <victortoso@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The record file uses fprintf to record commands and attributes.
On Windows line terminator uses ASCII format ("\r\n") while on
Linux it used UNIX format ("\n"). Open file as binary to use the
same line terminator on both systems.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Francesco Giudici <fgiudici@redhat.com>
Channel client creation can fail in some situation.
For instance if during a migration the client is disconnected.
In most cases this is ignored (this is usually logged in
red_channel_client_initable_init) but not in case of
CursorChannelClient and StreamChannelClient.
This fixes rhbz#1788757.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Julien Rope <jrope@redhat.com>
red_channel_client_shutdown remove the watch and shutdown the
socket. Reuse in red_channel_client_disconnect.
Calling shutdown will close the connection earlier.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
This information is retrieved multiple time.
Avoid to use just g_object_get which is dynamic so potentially
unsafe and slow.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
MainChannelClient is used by other clients to store some data
so should not disappear if other clients are still present.
Keep a owning reference to it and release after RedClient is
released.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Disconnecting a single channel from the client caused the server to
keep a stale channel client (RedChannelClient object) till the client
(RedClient object) entirely disconnected, that is the channel client
is disconnected but still in the list preventing new connections.
Calling red_client_remove_channel from red_channel_client_disconnect
fixes this last issue.
An issue was that was not clear how the ownership were managed. When
red_client_destroy was called red_channel_client_destroy was called
which freed the RedChannelClient object so this should imply
ownership.
However same red_channel_client_destroy call was attempted by
RedChannel using its list (red_channel_destroy). Basically the two
pointers (the one from the channel and the one from the client) were
considered as one ownership. To avoid the confusion now the client
list always decrement the counter.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
The channels list was not protected by a lock in red_client_destroy.
This could cause for instance a RedChannelClient object to be
created while scanning the list so potentially modifying the
list while scanning with all race issues.
Consider a client which attempt to connect to a new channel and
then for some reason close the main channel:
- the new channel connection is handled by the main thread;
- the relative RCC will be passed to red_channel_connect which
can decide to continue the initialization in another thread
(this happens currently for CursorChannelClient and
DisplayChannelClient);
- the main thread will catch the main channel disconnection and
call main_dispatcher_client_disconnect
(from main_channel_client_on_disconnect);
- main thread calls reds_client_disconnect;
- reds_client_disconnect calls red_client_destroy;
- now we have 2 thread which will attempt to change RedClient::channels
list, one protected by the mutex the other not.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
