[postgis-devel] malloc/palloc/lwalloc

[Paul Ramsey]

Makes sense. Grepping finds a few bare mallocs in there. Also lots of
lwalloc lwfree in the lwgeom area. Does the idea of a bare malloc make
any extra sense taken in combination with the fact that GEOS is going
to be doing bare malloc all over the place anyways? Or
memory-is-memory-is-memory?

P.

On Tue, Sep 23, 2008 at 1:15 PM, Mark Cave-Ayland
<mark.cave-ayland at siriusit.co.uk> wrote:
> Paul Ramsey wrote:
>>
>> I see that lwalloc traces back eventually palloc, and is there (?) to
>> provide a means to compile and use liblwgeom separate from pgsql. I
>> also see a few bare malloc calls, in the parser mostly, but also in
>> lwgeom_geos_c.c and wonder if there's any reason not to corral those
>> back into the pgsql process space?
>>
>> p.
>
> Okay. Given that there is probably little documentation on this, here is
>  how it works:
>
> - Everything under liblwgeom/ should call lwalloc()/lwfree() if memory is
> required. These will then automatically map to either standard
> malloc()/free() in the case of a standalone build, or palloc()/pfree() in
> the case of a PostgreSQL build. There should be no standard malloc()/free()
> calls in there - if there is, they need to be replaced.
>
> - Everything under lwgeom/ should call palloc()/pfree() since everything
> under this directory is only included in a PostgreSQL build.
>
> Does that make sense?
>
>
> ATB,
>
> Mark.
>
> --
> Mark Cave-Ayland
> Sirius Corporation - The Open Source Experts
> http://www.siriusit.co.uk
> T: +44 870 608 0063
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>