[geos-devel] Thread safe error handling

[Sandro Santilli]

On Mon, Sep 09, 2013 at 09:43:51AM +0200, Pepijn Van Eeckhoudt wrote:
> Hi Sandro,
> 
> I had a more in depth look at the code to see how this code be done. My
> proposal would be to add an extended message handler signature like
> 
> typedef void (*GEOSMessageHandler_r)(GEOSContextHandle_t *handle, void
> *userData, const char *fmt, ...);
> 
> and accompanying init and set...handler functions. The only real problem
> I ran into is that we wont be able to implement the old handlers in
> terms of the new ones since they're both variadic functions. That
> implies that we'll need a mode flag in struct GEOSContextHandleInternal
> and add conditionals around the handle->NOTICE and handle->ERROR calls.
> 
> Does the above acceptable to you?
> Which version of C/C++ can I use. I'm thinking of hiding the details of
> handle->NOTICE and handle->ERROR in a macro, but that would require
> variadic macro support (i.e., c99 and/or c++11).

Can't we turn NOTICE_MESSAGE and ERROR_MESSAGE into variadic methods
of the GEOSContextHandlerInternal class ? We could print to a string
and always pass a single string to the user-provided function, using
an hardcoded "%s" format for it.

--strk;

> 
> Pepijn
> 
> On za, 2013-09-07 at 15:32 +0200, Sandro Santilli wrote:
> > On Sat, Sep 07, 2013 at 01:23:25AM +0200, Pepijn Van Eeckhoudt wrote:
> > > Hi,
> > > 
> > > I'm using GEOS via the C api in libgpkg to implement geometry functions. I got the basics working now, but it feels like I had to jump through a lot of hoops to get the error handling set up reliably. The main problem I had was that there's no way to associate user data with the error and notice callbacks. Since this library may be used in a multi-threaded context I ended up having to use thread-local storage to store the error message. This feels more complicated than it should be.
> > > 
> > > Is there a simpler way to achieve the same result with the current API that I might have missed?
> > 
> > Not really. If you have ideas for extending the interface in a backward
> > compatible way, a patch would be accepted.
> > 
> > --strk;