As the tokens counter were not being reset you could enter in a
situation where client thinks it has more tokens then server which
would eventually lead to client's disconnection from 0c5eca97f1
onwards (before it was crashing).
It is easy to check the above situation if you track the amount of
tokens you have in the client and simply kill and restart the agent
while doing some file transfer: the client could reach more then 13
tokens which should not really be possible.
Based on patch from Frediano Ziglio <fziglio@redhat.com>
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This was proposed by Christophe as improvement over some typesafe
patches.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
This code make easier to be sure we don't have dangling pointers
resetting in the function which free the structure.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
RedCharDevice implementation had to callback into reds.c in order to let
it know a char device was being destroyed. Now that RedCharDevice is a
gobject, a weak reference can be used instead allowing to remove that
coupling.
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
There was an extra RedCharDeviceMsgToClientItem type whose only
purpose was to manage a linked list of items to send. GQueue has the
same purpose as this type in addition to being generic. As the length of
the send queue is tracked, a GQueue is more appropriate than a GList and
allow to remove RedCharDevice::send_queue_size.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Internally, use the method to set the 'sin' member variable so that we
don't have to duplicate the g_object_notify() calls, and there are
consistent debug statements whenever this value is modified. This also
means that we need to handle NULL arguments to this function.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since the type name was changed, use variable names / debug statements
that are consistent with the new name.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Since the device instance ("sin") is a gobject property, we should make
sure to notify when it changes, particularly since we do some
initialization in response to the "notify::sin" signal.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Now that all derived classes use a type deriving from PipeItem for their
RedCharDeviceMsgToClient, we can make this explicit in the
RedCharDeviceClass vfuncs, and remove the RedCharDeviceMsgToClient
typedef.
This structure holding virtual function pointers was kept until now as a
RedCharDevice member in order to make the GObject conversion easier.
Now that all RedCharDevice children are converted to GObject, it can be
moved into RedCharDeviceClass.
make the function names match the type names. So
spice_char_device_state_* becomes red_char_device_* and
spice_char_device_* also becomes red_char_device_*.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Make it consistent with the renamed RedCharDevice and the convention of
using 'Red' namespaces for internal types
Acked-by: Frediano Ziglio <fziglio@redhat.com>
This is more consistent with internal type naming convention, and it
paves the way for a new char device GObject heirarchy
Acked-by: Frediano Ziglio <fziglio@redhat.com>
Create a structure to hold private data.
This helps to make patch for GObject smaller.
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Add helper functions wrapping calls to the virtual functions
defined in SpiceCharDeviceCallbacks.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
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>
Since this is public API, we can't easily change the signature of the
function to take a RedsState argument, so instead we apply a hack and
store the reds argument inside the device state struct when the
interface is added, and retrieve it for use later when it is removed.
Acked-by: Pavel Grunt <pgrunt@redhat.com>
In preparation for getting rid of the global 'reds' variable, we need to
pass the RedsState variable to all functions where it is needed. For now
the callers just pass in the global reds variable.
Functions changed:
- reds_mig_fill_wait_disconnect;
- reds_mig_cleanup_wait_disconnect;
- reds_mig_remove_wait_disconnect_client;
- reds_migrate_channels_seamless;
- reds_mig_finished;
- reds_mig_switch;
- reds_enable_mm_time;
- reds_disable_mm_time;
- attach_to_red_agent;
- reds_char_device_add_state;
- reds_char_device_remove_state;
- reds_on_char_device_state_destroy;
- spice_server_char_device_remove_interface;
- migrate_timeout.
Acked-by: Frediano Ziglio <fziglio@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>
Some integer type definitions are different between 32 and 64 bit
systems which causes problems in printf. The PRI macros automatically
provide the printf format appropriate for the system.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
