>> On inspection, this was due to the 'unigine' application
>> created the HUD contexts twice (two screens?). The
>> extensions had never been tested in that configuration,
>> and the free_query_data() calls were thus trigger.
> The HUD is actually created per-context. Two general points that apply
> equally to all four parts of the patch:
Yeah. I didn;t realize this as none of the default use cases ever
exercised this approach.
Now that we have one, I'm happy to adjust it.
> Instead of open-coding the users variable, I'd prefer that you use the
> pipe_reference mechanism.
It would have been nice if a macro was global created for
of having to call (NULL, obj) and (obj, NULL), and read the code for
but this does not matter at this point.
> Contexts can be created and destroyed simultaneously from multiple threads.
In which case yes, we need some exclusivity, I've implemented this
> You probably need to protect some of the query functions with a mutex as
> well. The general rule of thumb is that functions associated to a
> Thanks for looking into this!
Thank you for the review. I should have a patch available shortly.
Steven Toth - Kernel Labs
mesa-dev mailing list