This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] Use timeout on xenstore read_reply to avoid task

To: Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Use timeout on xenstore read_reply to avoid task hunging
From: Frank Pan <frankpzh@xxxxxxxxx>
Date: Thu, 10 Mar 2011 18:54:32 +0800
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Jeremy Fitzhardinge <Jeremy.Fitzhardinge@xxxxxxxxxx>
Delivery-date: Thu, 10 Mar 2011 02:56:05 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=wjpZTqKvLIydQDuOzpxYElZGzCePkm0WZX51HJjW0X0=; b=RhrpKM2pPpxLFvCA8eW+45siVm16wudSKAgkc/hI2Fi4Q/ngd3Z/tM0Ydi1aa1fYNR DVo1zuPW1rUqcabboSjZ+YMxoaCED3c/0/4TAU8mwYnHquov0B43vrg1KhDJiMYsdGo1 tW4N9McdGLaeRH94yAM5hxXgHRu1P069Vg9Us=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=G4v9gkVXs3g3xAhdmYr6QTn8aowJPeVRj15GibeGqqlnI+Tlnj6AKq3I05rhKKtTCB d7zbTAH1f6wVevWWt4VjdyROwce19GJAbzUYo5Ij9CvuaQdphXbp1M4XdzJ+yT6rc4m8 kKeN3Y8AEZjDGVRV+oBl6qQBHTuyp4oC96+nc=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1299238262.6552.292.camel@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTimsaSKxCxRqBkpgVs30_jgdHrgw2ibFsU_gKCo6@xxxxxxxxxxxxxx> <1299062062.17907.1442.camel@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTim_L9Gkk7HYmSU9-ouEy+7Jo5uOZWbwx98T6eh+@xxxxxxxxxxxxxx> <1299238262.6552.292.camel@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> I think this is preferable to requiring all clients be reworked to
> handle a timeout event which they aren't currently expecting.

> Rather than have all xenbus clients expect and handle an arbitrary
> timeout we should provide a new interface to in-kernel users of xenbus
> which includes a timeout parameter, e.g. foo_timeout. (assuming there
> are in kernel users who could do anything sane with a timeout, if not
> then we shouldn't bother with the interface).

> For userspace clients I think we would probably be better off making
> sure that poll/select work properly than trying to find a way to expose
> timeouts of this sort, that combined with making the sleeps
> interruptible, would cover the problems we care about, I think.

How many clients are there? Is it possible to change them all?

Poll/select sounds great, but it may change the current xenbus protocol.
Also, if the protocol is changing, i think design a method to
determine whether xenstored is up is needed.

Can we alter xenbus protocol?

潘震皓, Frank Pan

Computer Science and Technology
Tsinghua University

Xen-devel mailing list