* Use of watch_pipe in xs_handle structure
@ 2014-02-14 2:09 Chris Takemura
2014-02-18 14:07 ` Ian Campbell
0 siblings, 1 reply; 2+ messages in thread
From: Chris Takemura @ 2014-02-14 2:09 UTC (permalink / raw)
To: xen-devel@lists.xen.org
Hi,
This message was also posted to the qemu-devel list, but I didn't get any
reply, and it occurred to me that it might make more sense here. Sorry if
you're reading it twice.
Anyway, I'm trying to debug a problem that causes qemu-dm to lock up with
Xen HVM domains. We're using the qemu version that came with Xen 3.4.2.
I know it's old, but we're stuck with it for a little while yet.
I think the hang is related to thread synchronization and the xenstore,
but I'm not sure how it all fits together. In particular, I don't
understand the lines in xs.c that handle the watch_pipe, e.g.:
/* Kick users out of their select() loop. */
if (list_empty(&h->watch_list) &&
(h->watch_pipe[1] != -1))
while (write(h->watch_pipe[1], body, 1) != 1)
continue;
It looks to me like the other thread blocks while reading from the pipe,
and the write allows it to continue. But this code seems like it does the
same thing as the condvar_signal call that comes slightly after, and
therefore it seems like I could safely #ifndef USE_PTHREAD it out. Is
this the case?
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Use of watch_pipe in xs_handle structure
2014-02-14 2:09 Use of watch_pipe in xs_handle structure Chris Takemura
@ 2014-02-18 14:07 ` Ian Campbell
0 siblings, 0 replies; 2+ messages in thread
From: Ian Campbell @ 2014-02-18 14:07 UTC (permalink / raw)
To: Chris Takemura; +Cc: xen-devel@lists.xen.org
On Thu, 2014-02-13 at 18:09 -0800, Chris Takemura wrote:
> Hi,
>
> This message was also posted to the qemu-devel list, but I didn't get any
> reply, and it occurred to me that it might make more sense here. Sorry if
> you're reading it twice.
>
> Anyway, I'm trying to debug a problem that causes qemu-dm to lock up with
> Xen HVM domains. We're using the qemu version that came with Xen 3.4.2.
> I know it's old, but we're stuck with it for a little while yet.
I'm afraid you are unlikely to get much specific interest in a 3.4.x
issue.
At the very least I would suggest an upgrade to 3.4.4.
Otherwise I'd suggest you at least skim the commit logs (at a minimum
for qemu-dm and libxenstore) for any interesting looking related fixes
which you are missing.
> I think the hang is related to thread synchronization and the xenstore,
> but I'm not sure how it all fits together. In particular, I don't
> understand the lines in xs.c that handle the watch_pipe, e.g.:
>
> /* Kick users out of their select() loop. */
>
> if (list_empty(&h->watch_list) &&
> (h->watch_pipe[1] != -1))
> while (write(h->watch_pipe[1], body, 1) != 1)
> continue;
>
>
> It looks to me like the other thread blocks while reading from the pipe,
> and the write allows it to continue. But this code seems like it does the
> same thing as the condvar_signal call that comes slightly after, and
> therefore it seems like I could safely #ifndef USE_PTHREAD it out. Is
> this the case?
I don't think so. The cond var is for libxenstore's internal
synchronisation, while the pipe is there to allow the calling
application to include xenstore in its select or poll based event loop.
Ian.
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2014-02-18 14:07 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-02-14 2:09 Use of watch_pipe in xs_handle structure Chris Takemura
2014-02-18 14:07 ` Ian Campbell
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).