Re: tools/libxl - Async Task Cancellation Query [and 1 more messages]

[Ian Jackson <Ian.Jackson@eu.citrix.com>]

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.