[Xen-API] Re: Xen-API C Bindings, version 0.4.1

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Thu, Aug 10, 2006 at 10:10:56PM -0400, Sean Dague wrote:

> On Thu, Aug 10, 2006 at 11:55:16AM +0100, Ewan Mellor wrote:
>
> [Snip]
>
> > OK, how's this:
> > 
> > I think that it's important to treat all return values the same, because I
> > want someone to be able to look at the Xen API document, the
> > language-independent one, and for them to be able to infer how the C API
> > should look.  Further, I worry about the case where a value doesn't have a
> > reasonable sentinel, such as an integer that can reasonably take any value 
> > in
> > the range.
> > 
> > Therefore, rather than
> > 
> > uint64_t result = xen_vm_get_thingy(session, param1, ..., paramn);
> > if (!session->ok) {
> >   // error handling
> > }
> 
> Based solely on grossness, the above makes me sort of ill.  It also means
> there would need to be some interesting locking on the session object if it
> is going to be thread safe.

Session objects _definitely_ aren't thread-safe.  If you want a multithreaded
client with a session pool or suchlike, then you need to impose a
coarse-grained lock around the session, so that you only use it from one
thread at a time.

> I don't like it.

That seems to be a common theme ;-)

> > how about we have instead
> > 
> > uint64_t result;
> > if (!xen_vm_get_thingy(session, &result, param1, ..., paramn))
> > {
> >   // error handling
> > }
> 
> While a little awkward, it is the very Cish way to do things.  It is
> especially important that any input params require the caller to manage the
> memory, otherwise things get nasty very quickly
> 
> > Personally, my choice would be for the first, but if the weight of the world
> > is against me, I can yield ;-)
> > 
> > This second form is no more complicated, so I can change the bindings over.
> > In particular, this means that there will be no remote call that returns 
> > void,
> > which is the thing that the Daniels didn't like.  Calls to the server that
> > return no result look like this instead:
> > 
> > if (!xen_vm_do_something(session, param1, ..., paramn))
> > {
> >   // Call failed
> > }
> > 
> > How's that for an alternative?
> 
> Yes, much better. :)

Consider it done!

Ewan.

_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api