[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v1 12/12] libxl: add device backend listener in order to launch backends
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |