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

[Rob Hoes <Rob.Hoes@xxxxxxxxxx>]

Hi Ian,

Sorry for taking so long to get back to you on this.

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

I have just submitted v5 of the (remaining) patches, where this solution is 
implemented.

> 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.

Indeed, but it is probably impossible to guarantee this, because it will not 
let you do much in the callbacks. Especially if we'd run a third-party event 
loop, we'd have to call library functions inside the callbacks which are not 
under our control.

>   * 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).

These are good options indeed, which we could use in xenopsd. However, they 
would not allow us to run a third-party event loop, for example from Lwt.

> > 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.

Good, that is clear.

Thanks,
Rob

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