|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH] libxen-3.0 (libxc rewrite)
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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
|
|