This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)

To: Ian Pratt <m+Ian.Pratt@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 22 Mar 2005 10:13:59 -0600
Cc: Christian.Limpach@xxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxxxx, ian.pratt@xxxxxxxxxxxx
Delivery-date: Tue, 22 Mar 2005 16:16:18 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <A95E2296287EAD4EB592B5DEEFCE0E9D1E37E3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
Organization: IBM
References: <A95E2296287EAD4EB592B5DEEFCE0E9D1E37E3@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0 (X11/20041206)
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.

Anthony Liguori


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
Xen-devel mailing list