Re: [Xen-devel] [PATCH 4/9] libxl_internal: Create new lock for devices hotplug via QMP

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Anthony PERARD writes ("Re: [PATCH 4/9] libxl_internal: Create new lock for 
devices hotplug via QMP"):
> So, instead of that interface, how about a different one that uses the
> same C type for both kind of lock?
> 
>     libxl__lock *libxl__lock_domain_userdata(libxl__gc *, libxl_domid);
>     libxl__lock *libxl__lock_domain_qmp(libxl__gc *, libxl_domid);
>     void libxl__unlock(libxl__lock *);

I think that would be fine.

> Or maybe avoid having two functions for locking and use a #define/enum
> instead:
>     libxl__lock_domain(gc, domid, LOCK_USERDATA);
>     libxl__lock_domain(gc, domid, LOCK_QMP);

Or this.

But I think maybe this conversation will be superseded by the need to
redo the implementation which will result in a totally different API
for the slow lock, and probably a different state struct.

> What do you think? Would the first proposal be enough to avoid having to
> write `userdata' or `qmp' twice on unlock?

I don't *mind* the writing `userdata' or `qmp' twice.  I just
discounting it as a *benefit*.  I mind the duplicated implementation
code.

> > Maybe it would be better to try once with LOCK_NB, and to fork if this
> > is not successful.  But it would be simpler to always fork...
> 
> After our talk IRL, I'll go the fork route.
> Also, I'm thinking to always fork when libxl is built with "debug=y",
> and allow the optimisation of trying first with LOCK_NB when built with
> "debug=n", so the forked code will actually be tested regulary.

Good plan.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel