FWIW this is what we have moved toward in Drizzle.
Cheers,
--Brian
On Apr 30, 2009, at 12:13 PM, Davi Arnaut <Davi.Arnaut@stripped> wrote:
> On 4/30/09 3:17 PM, MARK CALLAGHAN wrote:
>> On Fri, Oct 31, 2008 at 11:18 AM, Michael
>> Widenius<monty@stripped> wrote:
>>> Hi again!
>>>
>>>>>>>> "MARK" == MARK CALLAGHAN<mdcallag@stripped>
> writes:
>>> <cut>
>>>
>>> MARK> It would help if there were a document on the developer
>>> wiki page that
>>> MARK> stated this.
>>>
>>> http://forge.mysql.com/wiki/MySQL_Internals_How_to_allocate_memory
>>
>> Is there any chance we can get a per THD MEM_ROOT? There is not one
>> today so allocations for Security_context use the global pool
>> (malloc)
>> and then there is a need for Security_context::destroy. For the roles
>> support I have added I want to assign a string to
>> Security_context::priv_user that may require deallocation. It is
>> tricky to remember when that may be done because empty constant
>> strings are assigned to it ("") and non-empty constant strings are
>> assigned to it ("DELAYED" for delayed inserts). The current behavior
>> for priv_user is that it never requires deallocation.
>>
>> I will probably solve my problem by adding a buffer into
>> Security_context and using that buffer so I can avoid allocation.
>>
>
> The problem with yet another thd mem_root is defining it's lifetime,
> it can get hairy quite easy. Wouldn't it be better to be able to
> attach private data to a THD? This way a plugin (or anything else)
> can create its own mem_root and structures, attach it to a THD and
> retrieve it later when needed. I can scratch a proof of concept if
> it sounds okay..
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe: http://lists.mysql.com/internals?unsub=1
>
