So I've probed more deeply after my naive misunderstanding
of the consequence of the EAGAIN.
I believe I am closer to the source of the problem; I also
believe the problem is more serious than I realized; it's likely to bite
anyone trying the xspice solution quite hard.
That is, in spiceqxl_main_loop.c in the qxl X driver, there
is a basic implementation of watch_add/watch_update_mask.
The watch stuff is vital to retrying sends when they don't
go out due to a blocking condition.
However, that implementation does not function fully. It relies
on client activity on the X server to trigger a select polling
loop. But when sending the large initial network ping packet,
we have no client activity, and we just hang. The attached
patch 'improves' things, but I really have no sense as to whether
or not it would be a reliable solution.
I looked at trying to use the red_worker watch add stuff instead,
and I see that gets hairy. You need the watches before you
have a channel; the red_worker stuff relies on having a channel
to hang it's stuff off of.
But I have to confess it feels right - we've got our own thread;
we created the socket, and do all the listens/accept - why don't we
do our own watching?
Cheers,
Jeremy
diff --git a/src/spiceqxl_main_loop.c b/src/spiceqxl_main_loop.c
index 1718861..b06d5eb 100644
--- a/src/spiceqxl_main_loop.c
+++ b/src/spiceqxl_main_loop.c
@@ -317,7 +317,7 @@ static void select_and_check_watches(void)
static void xspice_wakeup_handler(pointer data, int nfds, pointer readmask)
{
- if (!nfds) {
+ if (!nfds && ring_is_empty(&watches)) {
return;
}
select_and_check_watches();
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel