From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vincent Hanquez Subject: Re: why xenstore-* hangs if xenstored is not started Date: Tue, 22 Jun 2010 09:27:41 +0100 Message-ID: <4C2073FD.5050800@eu.citrix.com> References: <4C206713.6030508@cn.fujitsu.com> <4C2069F2.9090408@eu.citrix.com> <4C206D34.1060909@cn.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4C206D34.1060909@cn.fujitsu.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Yu Zhiguo Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 22/06/10 08:58, Yu Zhiguo wrote: > Hi, > > Vincent Hanquez wrote: > >> That's the common behavior of task stuck in a kernel operation (ps aux >> will show the task at D, and /proc//wchan will tell you exactly >> where it's blocked in the kernel). >> >> the write is going to wait for a xenstored reply in kernel mode since by >> default the xenstore-* tools use the kernel xenstore page to communicate >> with xenstored. >> >> The unix socket operations doesn't have this "problems" (xenstore-* -s) >> > > Thanks~~ > I confirmed the task is at D+ and there are no this "problem" if use option -s. > But I think S+ is better than D+... I don't think it's very easy to have interruptible sleep here, it would change radically the protocol. the kernel xenstored page need to be handled "atomically" since requests and their replied cannot be intertwined. Maybe a timeout would be the one requiring the less change ? -- Vincent