Re: [Xen-devel] [PATCH v1 12/12] libxl: add device backend listener in order to launch backends

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH v1 12/12] libxl: add device backend listener 
in order to launch backends"):
> On Mon, 2013-11-04 at 17:59 +0000, Ian Jackson wrote:
> > +    assert(parent->magic == LIBXL__AO_MAGIC);
> 
> Is the intention to allow multiple levels of nesting or would it be a
> good idea to have an assert(!parent->nested) here?

I don't think there is anything wrong with multiple levels of nesting
although I'm hoping no-one will find a use for it!

> In either case it would be good to be explicit in the comment, either
> here or in the header.

Sure.

> >  /*
> > + * Short-lived sub-ao, aka "nested ao".
> > + *
> > + * Some asynchronous operations are very long-running.  Generally,
> > + * since an ao has a gc, any allocations made in that ao will live
> > + * until the ao is completed.  When this is not desirable, these
> > + * functions may be used to manage a "sub-ao".
> > + *
> > + * The returned sub-ao is suitable for passing to gc-related functions
> > + * and macros such as libxl__ao_inprogress_gc, AO_GC, and STATE_AO_GC.
> > + *
> > + * It MUST NOT be used with AO_INPROGRESS, AO_ABORT,
> > + * libxl__ao_complete, libxl__ao_progress_report, and so on.
> > + *
> > + * The caller must ensure that all of the sub-ao's are freed before
> > + * the parent is.
> 
> OOI what causes this requirement?

If there is no first-class ao running, then nothing might be running
the libxl event loop and the "escaped" sub-ao might never make
progress.

So the requirement is there to stop people writing a broken daemonic
sub-ao (ie, one which outlives its parent).  It's slightly stricter
than the actual requirement for correctness, which is that _some_ ao
must still continue.  But I'm hoping that no-one wants to have some
more complicated semantic relationship between a sub-ao and the
system's real ao's than parenthood.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel