1. 23 Jul, 2019 1 commit
  2. 22 Jul, 2019 1 commit
  3. 18 Jul, 2019 1 commit
  4. 11 Jul, 2019 12 commits
  5. 09 Jul, 2019 2 commits
  6. 08 Jul, 2019 3 commits
  7. 03 Jul, 2019 2 commits
    • Jakub Janků's avatar
      webdav: don't buffer input from phodav · 9f5aee05
      Jakub Janků authored
      The current approach with OutputQueue in webdav has several problems:
      
      * if the connection is slow, webdav keeps reading from phodav
      and pushing messages to the internal channel xmit_queue.
      This way, the queue can grow very quickly and the whole file
      that is being transferred using webdav essentially gets loaded into memory.
      
      * spice channel first flushes all messages in the xmit_queue and
      then proceeds to reading. If webdav floods the xmit_queue with
      a ton of messages, spice channel does not leave iterate_write until
      the queue gets empty. This way, reading from the channel is blocked
      till the whole file is transferred.
      
      * OutputQueue uses g_output_stream_flush_async() on SpiceVmcOutputStream
      that does not implement flush
      
      To solve these issues, don't read from phodav until the last message
      for a given client is written out to the socket.
      (main channel currently uses the same approach when transferring files)
      
      OutputQueue used an idle function to schedule the write and then
      called mux_pushed_cb which started reading from phodav with priority
      G_PRIORITY_DEFAULT.
      Since this new approach does not utilize the idle scheduling,
      lower the priority in client_start_read() to G_PRIORITY_DEFAULT_IDLE
      to make sure other sources with lower priority get dispatched as well
      (e.g. signals from coroutines, redrawing and resizing operations).
      
      Also implement spice_webdav_channel_reset(). This is necessary because
      spice_vmc_write_async() references the channel. If the channel is to be
      disconnected, the write operations need to be cancelled so that
      the references to the channel are released asap. Otherwise,
      spice session would be stuck waiting for the channel to finalize.
      Signed-off-by: Jakub Janků's avatarJakub Janků <jjanku@redhat.com>
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      9f5aee05
    • Frediano Ziglio's avatar
      channel-webdav: Write mux message in a single memory block · b229bb09
      Frediano Ziglio authored
      Reduce number of write to the channel.
      This will also help making the write to socket all asynchronous
      avoiding potential blockages.
      Signed-off-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      Acked-by: Jakub Janků's avatarJakub Janků <jjanku@redhat.com>
      b229bb09
  8. 02 Jul, 2019 1 commit
  9. 01 Jul, 2019 2 commits
  10. 26 Jun, 2019 1 commit
  11. 25 Jun, 2019 3 commits
    • Frediano Ziglio's avatar
    • Francois Gouget's avatar
      channel-display: Rename the frame mmtime variables · 70de8a45
      Francois Gouget authored
      The point of the mmtime timestamps is that they are the same on the
      server and client thanks to the client running its own mmtime clock
      synchronized, modulo a server-controlled offset, to the server's
      mmtime clock.
      So the frame mmtime timestamps are neither tied to the server nor the
      client. They are however tied to the frame.
      Signed-off-by: default avatarFrancois Gouget <fgouget@codeweavers.com>
      70de8a45
    • Jakub Janků's avatar
      file-transfer-task: emit signals in main context · 2261e50a
      Jakub Janků authored
      Parts of the internal file transfer task API can be invoked in the
      coroutine context, so in these cases use g_coroutine_signal_emit and
      g_coroutine_object_notify.
      
      Some functions (such as spice_main_channel_clipboard_selection_grab) wake
      up the channel and thus can immediately switch to the coroutine context.
      Delivering signals in the coroutine context as well, could theoretically
      lead to problems with reentrancy, since the user of spice-gtk does not
      expect this behavior.
      Spice-gtk, on the other hand, assumes that the public functions are called
      from the main context. So calling
      spice_main_channel_clipboard_selection_grab from the coroutine context
      prints an error as we try to switch to a coroutine we are already in.
      
      Such issues are probably not likely, but the fix is easy.
      Signed-off-by: Jakub Janků's avatarJakub Janků <jjanku@redhat.com>
      Acked-by: Frediano Ziglio's avatarFrediano Ziglio <fziglio@redhat.com>
      2261e50a
  12. 19 Jun, 2019 5 commits
  13. 18 Jun, 2019 5 commits
  14. 14 Jun, 2019 1 commit