Re: [Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: event management [and 1 more messages]

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Rob Hoes writes ("RE: [Xen-devel] [PATCH v2-resend 22/30] libxl: ocaml: event 
management [and 1 more messages]"):
> [Ian Jackson:] 
> > I'm not sure how that would help.  libxl already has a mutex which it takes
> > on entry, so all calls into libxl are already mututally exclusive.
> > 
> > What would happen if your fd registration callback ocaml code tried to make
> > a libxl call ?
> 
> Ok, what I said was not quite right. You are referring to the fact
> that libxl keeps hold of its lock in the fd registration callback. A
> possible deadlock scenario like the following may then occur:
> 
> [diagram]

Exactly.

> The experts here have suggested that the common thing to do is to
> release the ocaml heap lock when calling libxl functions, and
> reaquire it when returning or calling back into ocaml. I tried to
> avoid this, because it complicates things, but it seems I have no
> choice now :)

That would be one way to do it.  It's the way it's done in libvirt.

Other possibilities that come to mind are:

  * Somehow ensure in the ocaml code that a thread processing a libxl
    fd registration registration never calls any blocking C functions
    which would drop the ocaml lock.  I'm not sure how easy this would
    be in ocaml.

  * Have fd and timeout registrations put on a queue in the C code in
    the ocaml bindings, and process them later with the ocaml lock
    held.  Although if you do this you need to make sure that the
    queue is looked at before delivering any events, and you would
    need a way to wake up your event loop in another thread to tell it
    that there were fd/timeout registrations which it needs to deal
    with.

  * Use the beforepoll/afterpoll functions rather than the
    registration machinery.  This would be quite workable from a
    performance point of view if each of your processes handles a
    single domain (or only a few).

> In this case, the ocaml heap lock is never held together with the
> libxl lock, except in the registration callbacks. If we then promise
> to not call any libxl functions inside the callback, I think we can
> avoid deadlocks.

Yes.

> The picture becomes as follows:
> [diagram]

Yes, precisely.

> Does that sound right?
> 
> How about event_occurs callback, and async callbacks? Is the situation the 
> same?

The event occurs and async completion callbacks are made by libxl with
the libxl lock _released_.  The libxl machinery queues them up
internally to make this possible.  So they aren't affected by these
restrictions.

Ian.

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