[postgis-devel] WKTRaster & liblwgeom : thread safety

[strk]

On Mon, Jan 26, 2009 at 11:54:17AM +0000, Mark Cave-Ayland wrote:

> In terms of work required, it won't really affect the user interface and 
>  if there are any bugs then they will show up fairly quickly - it's 
> mainly just spending the time to redo all of the function calls. The 
> hard part will be working out how to pass the context into PostGIS after 
> PostgreSQL startup, since we are aiming to support 8.1, and 8.1 doesn't 
> have PG_init.

We're currently calling the externally-provided lwgeom_init_allocators
everytime an allocation/release/message is required, might as 
well call the context-retriving function at PostgreSQL function
entry point instead. Would be even less calls.

We could cache the context in the extention lib (in a function-static)
like this:

static rt_context
get_context(FunctionCallInfoData *fcinfo)
{
    MemoryContext old_context;
    static rt_context ctx=0;

    if ( ctx ) return ctx;

    /* We switch memory context info so the rt_context
     * is not freed by the end of function call
     * TODO: check _which_ context we should be using
     * for a whole-plugin-lifetime persistence */
    old_context = MemoryContextSwitchTo(fcinfo->flinfo->fn_mcxt);
    ctx = rt_context_new(rt_pgalloc, rt_pgrealloc, rt_pgfree);
    MemoryContextSwitchTo(old_context);

    rt_context_set_message_handlers(ctx, rt_pgerr, rt_pgwarn, rt_pginfo);

    return ctx;
}

Then obtain the context from functions:

 PG_FUNCTION_INFO_V1(RASTER_in);
 Datum RASTER_in(PG_FUNCTION_ARGS)
 {
   rt_context ctx = get_context(fcinfo);
   ...
 }

For liblwgeom it will be an lw_context most likely,
and our rt_context could hold a pointer to lw_context itself
for use of liblwgeom...

> In short, if you wish to do the work and provide a patch, I'd be happy 
> to help you with it.

Right. Lots of work though, not sure it's worth the current
fundings for WKTRaster.

--strk;