[postgis-devel] WKTRaster & liblwgeom : thread safety

Mark Cave-Ayland mark.cave-ayland at siriusit.co.uk
Mon Jan 26 03:54:17 PST 2009


strk wrote:

> 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 ?


Hi strk,

I am actually not opposed to making the liblwgeom API thread-safe as I 
think this would be a good thing, and I like your function pointer 
notation above.

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.

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


ATB,

Mark.

-- 
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063



More information about the postgis-devel mailing list