[OpenSER-Devel] RFC: memory management in database modules

Daniel-Constantin Mierla daniel at voice-system.ro
Tue Feb 5 16:55:59 UTC 2008


On 02/05/08 18:38, Henning Westerholt wrote:
> On Tuesday 05 February 2008, Daniel-Constantin Mierla wrote:
>   
>>> [..]
>>> At the moment there existing two different styles:
>>>
>>> mysql, unixodbc don't allocate new memory and just assign the string
>>> pointer of the result set to the internal OpenSER representation. The
>>> modules that needs to use this results needs to copy them, because there
>>> are not available after a call to the DB specific result free function.
>>>
>>> postgres, db_berkeley allocate new memory and copy all string values from
>>> the database to the internal representation. Modules that uses this
>>> driver don't need to copy there values, even after the freeing of the
>>> result set.
>>>       
>> quite strange, if the copy is not freed with free_result(), when it
>> happens? At first thought, seems exposed to memory leak.
>>     
>
> The copy is eventual freed with free_result(). The difference is only the copy 
> operation that takes place.
>   
ok, maybe I have misunderstood what you meant.

>   
>> db_berkely seems constructed on dbtext structure. In dbtext, the result
>> is duplicated in private memory, as the tables are stored in shared
>> memory, and making direct references will be exposed to race.
>>     
>
> Ok, i don't thought that much about this issues with dbtext yet..
>
>   
>> I think that the driver modules should not duplicate the result unless
>> there is some race in reading/writing values in the result. Each module
>> that uses the driver decides whether it needs values after free_result()
>> and does a copy -- this is how should be now, at least did so.
>>     
>
> Well, ok. Perhaps we can introduce a flag in the db_val or db_row type, that 
> indicates that STR, STRING and BLOB values are copied, and thus needs to be 
> freed? This would make it possible to use the same free function for the 
> different databases, without changing that much of the internal logic of the 
> driver.
>   
Seems the right approach, to mark whether the value should be freed by 
the openser db driver module or is done when freeing the result from the 
db library used beneath. I think it is at value granularity, as the row 
has different value types and in some cases, even for same type it is no 
need if the openser db driver module didn't changed the value returned 
by db library.

Cheers,
Daniel


> Henning
>
> _______________________________________________
> Devel mailing list
> Devel at lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/devel
>
>   



More information about the Devel mailing list