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
|
Home