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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event generation 
API"):
> On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> > Well, we have to have an internal version because we don't want to
> > call GC_INIT again, obviously.
> 
> In this case it would take a ctx not a gc and it's ok and expected for
> libxl a function calling another libxl function to end up with another
> gc in the inner function (it happens all the time).

This is not allowed in functions which might generate events (ie,
which might call libxl__event_occurred), because the application's
event callback will be called at an unexpected point in libxl's
execution.  This has three problems:

 * There is a reentrancy hazard.  Exactly whether this is a problem in
   a specific case is difficult to analyse; hence the recording of
   pending callbacks in the gc, so that they can be delayed until the
   gc is freed.

 * The application's callbacks will be called with the libxl ctx
   locked.  This might result in deadlock.

 * The  application's callbacks  might be  called in  the  wrong order
   because the  inner gc (containing  later events) is  unwound before
   the outer gc (containing earlier events).

In general this means that functions which lock the ctx must not
allocate an inner gc.

> IOW if you make beforepoll_internal take the lock as you suggest then
> you may as well inline it into libxl_osevent_beforepoll (removing the
> second lock use) and use that internally too.

beforepoll_unlocked is called in two places: libxl_osevent_beforepoll,
and libxl_event_wait.

Ian.

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