[postgis-devel] WKTRaster & liblwgeom : thread safety

[strk]

Hi all.
While interfacing to liblwgeom from WKTRaster in order
to implement vector construction from rasters I've
hit a limit preventing WKTRaster api from being thread-safe.

Is not a big deal for the project in this stage, but
for future improvements it might be worth thinking
about how to make that possible.

In particular, I've started the WKTRaster api by
defining a 'context' structure to hold memory management
and info reporting functions, similarly to what the
set of (lwalloc_var, lwrealloc_var, lwfree_var,
lwerror_var, lwnotice_var) accomplish for liblwgeom,
just into a structure that is passed around.

The context struct looks like this:

 typedef void* (*rt_allocator)(size_t size);
 typedef void* (*rt_reallocator)(void *mem, size_t size);
 typedef void  (*rt_deallocator)(void *mem);
 typedef void  (*rt_message_handler)(const char* string, ...);

 struct rt_context_t {
     rt_allocator alloc;
     rt_reallocator realloc;
     rt_deallocator dealloc;
     rt_message_handler err;
     rt_message_handler warn;
     rt_message_handler info;
 };

It allows for doing things like:

 void a_func(struct rt_context_t* ctx)
 {
	void* mem = ctx->alloc(32);
	ctx->info("Allocated 32 bytes @ %p", mem);
	mem = ctx->realloc(mem, 64);
	ctx->warn("Reallocated to %p", mem)
	ctx->dealloc(mem);
	ctx->err("Catastrophe, %p is gone!", mem)
 }

The structure is passed around to all functions of the API,
allowing for messages to come out from wherever.

Now, when it comes to interface to liblwgeom, we basically
loose any possibility to hook on the context, as liblwgeom
relies on that lib-static set of routines instead.

As an aim to integration I could drop the thread-safety
as a whole and use the same schema for those utility
functions. Or, we can modify lots of liblwgeom to allow
for thread-safety.

Your thougths on the matter ?

--strk;

 Free GIS & Flash consultant/developer      ()  ASCII Ribbon Campaign
 http://foo.keybit.net/~strk/services.html  /\  Keep it simple!