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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2011-12-12 at 11:40 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] [PATCH 15/15] libxl: New event 
> generation API"):
> > Stepping back a bit: Since the lock is recursive do we really need the
> > unlocked version? All the callers of event_check_unlocked (apart from
> > libxl_event_check) could call libxl_event_check instead.
> 
> 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).

> Since the callers all take the lock the internal version doesn't have to.
> 
> It would be possible to have these functions pointlessly reacquire the
> lock, I guess, and rename it to "beforepoll_internal" etc.

My point was that the "unlocked" version of the function makes naming
the function confusing (or at least has led to some degree of
bikeshedding) and that there is nothing wrong with pointlessly taking a
recursive lock twice so we could avoid the issue by just having the
external version and using it internally as well.

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.

Ian.



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