On Fri, Jul 10, 2009 at 19:56, Eric Anholt<[email protected]> wrote:
> On Fri, 2009-07-10 at 11:24 +0200, RALOVICH, Kristóf wrote:
>> Please don't applies these right now. I am in the process of revising
>> them since there might be a simpler approach to the problem.
>
> Excellent, I'd been delaying reviewing it because it looked more
> complicated than I hoped :)

Probably excellent from the POV of the reviewer, but the situation in
the GLX code is far from excellent...

>
> --
> Eric Anholt
> [email protected]                         [email protected]
>
>
>

I will try to explain the situation here (I am going to talk only
about the DRi2 case, but this mostly applies to both DRI and DRISW
paths too): driver_configs in dri2CreateScreen() is leaked.


Lines 488-489 in dri2_glx.c populates psc->configs and psc->visuals,
prior to that the local array driver_configs is allocated and filled
with visual descriptions supported by the actual DRI driver, now
driConvertConfigs makes these two (psc->configs and psc->visuals)
reference some (or all) parts of driver_configs. Some configs may be
referenced multiple times, some are not referenced at all.

Nevertheless we would like to free driver_configs properly at
destruction time and release the unreferenced parts right the way
(driDestroyUnmatchedConfigs() ).

My first patche series posted did this, by "disassembling"
psc->configs and psc->visuals during tear down to have the remainings
of driver_configs freed only once. This approach was ugly and required
much magic. That's why Eric didn't like it. I agree with him now as I
have thought more about the problem.

By the time I have posted my 2nd generation of patches only
implementing driDestroyUnmatchedConfigs(), this still follows the
previous way we have just declared ugly.

So what I am proposing now is to extend __GLXscreenConfigsRec with the
field driver_configs. This would allow us make screen destruction
simple and 100% leak free and as a bonus to avoid
driDestroyUnmatchedConfigs() (drawing my 2nd patch series unnecessary
too). Also this would require the least intrusive patch in my opinion.

Any comments are welcome!

Kristof

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize  
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Mesa3d-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev

Reply via email to