[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] tools/libxl - Async Task Cancellation Query [and 1 more messages]
Koushik Chakravarty writes ("RE: tools/libxl - Async Task Cancellation Query"): > When you say - " That would require the caller to preserve the ao_how which > seems awkward to me " - whom do you refer as the caller? By the caller I mean the program outside libxl which is calling libxl. > >From what I picked up, the libxl_ao_cancel() API is passed with the ao_how. > >The libxl_ao_cancel then looks into the ctx->aos_inprogress list to find the > >ao that matches the ao_how. Yes. > So what I was suggesting was that if the ao_how was allotted an 'id' from the > original libxl api call (done using a counter increment from the global libxl > ctx with a lock held), and the same id was saved in the ao entry in > ctx->aos_inprogress, then searching/matching them in libxl_ao_cancel() would > have been a little faster. Sorry, I had misunderstood. I thought you were proposing some kind of arrangement where libxl would be able to look up the relevant ao in O(1). That would require either the lifetime of these ids to be controlled. But now I understand that you're just proposing a pure id which still requires a search. I don't think the performance benefit is really worthwhile for the extra complexity. This is particularly true given that currently the ao_how is const. So the caller might have defined it as `static const' and put it in the text segment. Changing the API to make this parameter non-const sometimes, in a backward compatible way, would be a bit complicated. But thanks anyway for your suggestion. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |