Re: [PATCH 2/2] libxl: fix stale timeout event callback race

[Jim Fehlig <jfehlig@suse.com>]

Ian Jackson wrote:
> Jim Fehlig writes ("Re: [Xen-devel] [PATCH 2/2] libxl: fix stale timeout event callback race"):
>   
>> Ian Campbell wrote:
>>     
>>> One option is to add new hooks which libxl can call to take/release the
>>> application's event loop lock + a LIBXL_HAVE_EVENT_LOOP_LOCK define so
>>> the application can conditionally provide them.
>>>       
>> libvirt's event loop lock is private to the event impl and not exposed
>> to its numerous users.
>>     
>
> Right.  I still think it might be useful to provide a way for a
> consenting application to allow libxl to use the application's event
> loop lock (perhaps, its single giant lock) as the ctx lock.  If it had
> been possible in this case it would have eliminated these particular
> races, so it's a benefit for those applications.  And the extra
> complexity doesn't seem likely to introduce other bugs.
>
> But I think we should fault that feature in when we have a potential
> user for it, and from what you say that's not libvirt.
>   

Correct.  That approach doesn't really fit with libvirt's generic event
loop used by the various drivers.  I suppose the libxl driver could have
a private event loop, but I'd prefer to keep the pattern used by other
drivers.

Regards,
Jim