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

[Anthony Liguori <aliguori@us.ibm.com>]

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