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

[Sean Dague <japh@xxxxxxxxxx>]

On Thu, Aug 10, 2006 at 11:55:16AM +0100, Ewan Mellor wrote:
> On Thu, Aug 10, 2006 at 12:51:57AM +0100, John Levon wrote:
> 
> > On Wed, Aug 09, 2006 at 05:26:34PM +0100, Ewan Mellor wrote:
> > 
> > > >   Sorry, that's horrible, because you loose locality of the error.
> > > > Errors should be detected as soon as possible to be able to report 
> > > > them as accurately as possible.
> > > 
> > > If you want to detect them as soon as possible, just have if (session->ok)
> > > after every call.  It's no harder than if (return_value == 
> > > NULL/-1/0/false).
> > 
> > I don't think the issue is whether it's possible to do so, but whether it's
> > natural. It's rather unnatural IMO to have this out-of-band error 
> > notification
> > in a C API. It's hard enough to get people to check return values when they
> > exist, never mind when they're implicit. (Yes, people should always strive 
> > to
> > get this right, but the perfect never happens, so it's really all about
> > minimising the error as much as possible...)
> 
> 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.  I don't like it.

> 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. :)

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

-- 
Sean Dague
IBM Linux Technology Center                     email: japh@xxxxxxxxxx
Open Hypervisor Team                           alt: sldague@xxxxxxxxxx

Attachment: pgp9bEDv0WcKN.pgp
Description: PGP signature

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