Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Stefano Stabellini writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event 
generation API"):
> +#define GC_INIT(ctx)  libxl__gc *gc = libxl__init_gc(ctx); if (gc == NULL) 
> return ERROR_NOMEM;

One of my key objection to this is here.  I think that a convenience
macro should be written to avoid returning from the calling function
whereever possible.  And here, it is possible.

My other key objection is that I disapprove of the additional dynamic
allocation step, which provides additonal scope for bugs.  Dynamic
allocation with manual memory management should be avoided where it is
not necessary.  In general code should be structured so as to minimise
undetected mistakes by the programmer, which this is not.

Indeed your first version attempt at this approach has two such bugs!

Converseley the programming mistake you are trying to eliminate, of
calling an event-generating function from elsewhere in libxl, is not a
trivial mistake.

Firstly, it can only result from a fundamentally wrongheaded approach
to writing an asynchronous function.  In the correct approach the
desire to call an event-generation function (whether a slow function
like a synchronous ao call, or such as an event callback) from other
non-event-related libxl functions should not arise.

Secondly, the restriction is now enforced by the type system.

So the programmer can forget about this restriction unless they are
actually modifying the core event machinery.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel