[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 06/35] libxl: Use ev_qmp for switch_qemu_xen_logdirty
Anthony PERARD writes ("Re: [PATCH 06/35] libxl: Use ev_qmp for switch_qemu_xen_logdirty"): > On Tue, Sep 17, 2019 at 05:52:24PM +0100, Ian Jackson wrote: > > I hate to suggest this at this stage, but: maybe the timeout could be > > incorporated into libxl__ev_qmp ? > > > > I think every libxl__qmp caller is going to need a timeout ? > > Yes, every user of libxl__ev_qmp should have a timeout set up. But > there are different way to set it up. When we have several command to > send via QMP should we have a new timeout for every command or set only > one when sending the first command, and only stopping the timeout when > the last command's response have been received? In this patch series > I've choose the second option. > > I can see several cases: > - One QMP command > -> easy, one timeout for it. > - several commands, related or not. > -> one timeout per command? or one timeout which cover all of them? > one per commands means that a bad qemu could delay the operation > several time longer than if there were a single timeout covering > all the commands. > - other slow operation are done beside a qmp command > -> In this case, it might not be practical to have a timeout attach > to the qmp command, we are going to need a timeout for the other > operations. Hmmm. Yes. You have obviously considered this better than me.q > I guess we could try to optimise the simpler case when there is only one > qmp operation, because that's the most common, but allow to send > commands without having libxl__qmp setting a timeout. That would be nice. I think this is a nice-to-have, not a blocker. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |