[Spice-devel] Release the androidSpice-0.1.3 experimental.

[Shuxiang Lim]

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 <shohyanglim at gmail.com> 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 <shohyanglim at gmail.com>
> 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 <shohyanglim at gmail.com> 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,
>> >     --林
>> >
>>
>