Hi,

After debugging, I  think my problem is probably not accociated with 
cooperative multitasking.
Here is where spice-gtk read data:


    /* treat all incoming data (block on message completion) */
    while (!c->has_error &&
           c->state != SPICE_CHANNEL_STATE_MIGRATING &&
           g_pollable_input_stream_is_readable(G_POLLABLE_INPUT_STREAM(c->in))
    ) { do
            spice_channel_recv_msg(channel,
                                   
(handler_msg_in)SPICE_CHANNEL_GET_CLASS(channel)->handle_msg, NULL);
#ifdef HAVE_SASL
            /* flush the sasl buffer too */
        while (c->sasl_decoded != NULL);
#else
        while (FALSE);
#endif
    }




If vdagent sends lots of data, spice_channel_recv_msg will be called the whole 
time, so iterate_write will not be called, and data will not be sent out unless 
vdagent stops sending data.


BR
Don










At 2020-06-13 14:40:02, "Frediano Ziglio" <fzig...@redhat.com> wrote:

Hi,
  the pattern used in spice-gtk is called cooperative multitasking (see 
https://en.wikipedia.org/wiki/Cooperative_multitasking), if you add code that 
is not cooperative you get what you described. Use coroutine functions to read 
remote data so the read won't stop other code. If you need to run expensive or 
blocking code it's a good idea to run it in another thread removing the 
blockage.



Frediano







Hi 


Here is my experiment:
I created a new port-channel to transfer data between vdagent and spice-gtk. I 
used a while loop to send 2kb data to gtk, gtk received and drop the data. In 
the mean time I used a timer(1ms) to send 2kb data to vdagent. 
Strange thing is that gtk will continually receive data for a while(10secs - 
70secs) then send a whole bunch of data to vdagent. When receiving data, send 
data will be added to tcp buffer but will not be sent out.


So I think send event will be affected by receive event, then I guess using 
different thread would help. 
Could you please correct me if I’m wrong?


BR
Don
















在 2020-06-12 20:03:30,"Marc-André Lureau" <marcandre.lur...@gmail.com> 写道:

Hi



On Fri, Jun 12, 2020 at 12:57 PM 陈炤 <qishiye...@126.com> wrote:

Hi,


Spice-gtk is now using co-routine to handle different channel connections. When 
a channel is handling data, other channels would have to wait, rather than 
handling synchronously.  That would bring us following issues:
 1. If some less important channels (like usb channels) are transfering big 
data, important channels (main-channel, display-channel,input-channel) will be 
affected.  
 2. When receiving big data like file transfering(G_IO_IN), send event 
(G_IO_OUT) will not be triggered.
 3. Flow control between different channels will be hard to do. 


Is is possible(and make sense) to put channels into different threads so they 
can synchronously receive & send msg, without affect each other?




Switching to threads would be possible, but that wouldn't help in the situation 
you describe, as you are very likely bound on IO. Using several threads would 
actually create more problems to synchronize and schedule the different 
channels.


Io operations in coroutines are non-blocking, so they shouldn't affect other 
spice-gtk task. If you however observe a blocking CPU-task in some channel, 
this may affect the performance of other channels. But in general, except for 
video/image decoding which may be done in a separate thread, the client side 
doesn't do much work.


USB, clipboard and file sharing may use large amounts of data, and we rely on 
the glib source and kernel to prioritize channels: this isn't great in some 
cases and may receive improvements.




--

Marc-André Lureau






 


_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel


_______________________________________________
Spice-devel mailing list
Spice-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/spice-devel

Reply via email to