[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 15/15] libxl: New event generation API
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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |