Hi, Well,since I really don't want to get into the dirt of coroutine_*() funcs, I force the input-channel to be ready in spice-channel.c by change ret = g_io_wait_interruptable(&c->wait, c->sock, G_IO_IN); to ret = G_IO_IN;
Now,anyway,IT WORKS,it will never hesitate to receive data from server,thus the choking and yieldto()-->abort()-->segfault will not happen any more,cheers! BTW,is there any danger in such gory modification? Is there some better way? Today will be a gorgeous spring day! Best Regards. --Lin--林------------------------ On 4/26/11, Shuxiang Lim <[email protected]> wrote: > Now confirmed,it will fall in dead loop in spice_channel_iterate() for > g_io_wait_interruptable()-->coroutine_yield()-->coroutine_swap() because > coroutine_swap() always returns NULL, how to fix this? Any spice-gtk guys > can help me? > Rgrds. > > On Mon, Apr 25, 2011 at 9:08 PM, Shuxiang Lim <[email protected]> > wrote: > >> After some tracing work: I found that,when no input occurs in the >> client,the output flow from server to client may be jammed by the slow >> network but will never be choked.But when there's input, the client >> will always fall soon in the endless calling for coroutine_yield() and >> coroutine_swap() in coroutine_gthread.c (for threads prior >> swapping???why should this?) and usually cause the "yield to >> itself"-->abort() -->segfault. Thus,client will have no mood to >> receive data from server at all,and the output will be choked(input >> still OK). >> So,why does such dead-lock-liked thing happens only on android,how >> can I fix this,or how can I disable such Swapping? Any ideas? >> Rgrds. >> >> >> On 4/25/11, Shuxiang Lim <[email protected]> wrote: >> > Hi,all! >> > I'm happy to release the experimental androidSpice under >> > LGPL,welcome >> to >> > improve! >> > The source and wiki now dwell in google code site here: >> > http://code.google.com/p/spice-client-android/ >> > All introductions of porting can be found or redirected in the wiki >> > page. >> > >> > The structure of androidSpice: >> > 1.Data layer,extracted from spice-gtk-0.5, the main logic and data >> > transportation/proccessing of spice protocol,along with all its >> > dependencies,built statically into libspicec.so >> > 2.Data layer will add two new threads in android-worker.c for the I/O >> with >> > Java UI layer via UNIX-sockets(see the PROBLEMS below) >> > 3.UI layer,rewritten in Java. Output the Images and capture user-input >> > events and communicate with libspicec.so. >> > >> > PROBLEMS: >> > >> > "The damned greatest obstacle I've faced in the porting lies in the >> > structure of Android itself:It has no(at least for version<2.3 ) >> > exposed >> > audio/image output and input API for C(only Java!)! So I have to >> transport >> > all the fixed data got from spice-server to Java layer by adding two >> > new >> > threads to handle the I/O communication with Java UI via two >> > UNIX-sockets,that's the leg-drawing of speed. Besides, quic.c in client >> is >> > buggy of SIGBUS or SIGSEGV on android(anyone can fix it?thx!),I have no >> > better way but to force use of JPEG compression in server and the >> > client >> > will send jpeg data directly to Java UI for output, it's queer and >> > should >> > be >> > condemned('cause Spice's value is in the image processing ability)" >> > >> > So now It just WORKS,but works badly, the first untolerable bug is this >> > >> > Bug 1:If press fast on the device the spice-server as well as the >> > android-spice-client will be choked and no image updates will be sent >> > out >> > from server. >> > I'm still working on this bug,I need help! >> > >> > Best regards, >> > --林 >> > >> > _______________________________________________ Spice-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/spice-devel
