From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH] libxen-3.0 (libxc rewrite) Date: Tue, 22 Mar 2005 10:13:59 -0600 Message-ID: <42404447.9070507@us.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Ian Pratt Cc: Christian.Limpach@cl.cam.ac.uk, xen-devel@lists.sourceforge.net, ian.pratt@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org Ian Pratt wrote: >Personally, I think the best approach is to stick with the existing C >convention that everyone is already well familiar with, and have a >separate errno variable. This means we can then have functions return >pointers etc rather than having to pass them by reference, which is >undeniably ugly. > > There's only one problem with this: thread-safety. I believe errno is commonly implemented in thread-local storage. We'd have to jump through major hoops to get our own proper errno. Returning the error as part of the interface makes life a lot easier for threading. However, it sounds like a lot of people don't like this. The best alternative would be to have a context for the library (not just a simple file descriptor, but an actual struct that contained the file descriptors and the current error condition). I really was hoping to avoid requiring a context (it simplifies application programming tremendously). Does anyone have an idea for making a libxen errno thread safe that wouldn't require a context? >I notice that you store the fd of the priv_cmd in a static variable. I >guess this is OK, but I think I still prefer a way of explicit way of >closing the fd. You'd also have to be a little bit careful about someone > > Ok. Not a problem. >forking then two guys trying to open the fd at the same time. > > Yes, I was actually considering the case of two threads when I wrote the library. That's why I exposed hcall_init() as part of the public interface. It allows a threaded app (or a forking() app) to ensure that the library is only initialized once. Regards, Anthony Liguori >Ian > > > > ------------------------------------------------------- This SF.net email is sponsored by: 2005 Windows Mobile Application Contest Submit applications for Windows Mobile(tm)-based Pocket PCs or Smartphones for the chance to win $25,000 and application distribution. Enter today at http://ads.osdn.com/?ad_id=6882&alloc_id=15148&op=click