|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] Use timeout on xenstore read_reply to avoid task
> 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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|