From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Takemura Subject: Use of watch_pipe in xs_handle structure Date: Thu, 13 Feb 2014 18:09:33 -0800 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Language: en-US List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.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?