From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Jackson Subject: Re: tools/libxl - Async Task Cancellation Query [and 1 more messages] Date: Tue, 14 Apr 2015 11:02:17 +0100 Message-ID: <21804.58793.408184.86239@mariner.uk.xensource.com> References: <21797.3921.740361.402596@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: , List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Koushik Chakravarty Cc: "'xen-devel@lists.xensource.com'" , Euan Harris List-Id: xen-devel@lists.xenproject.org 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.