[geos-devel] Proposal: Thread safe CAPI

[Chuck Thibert]

Thanks for the great feedback Frank.  I will implement the suggestions.
As for the TS versions of functions that don't quite need it... Mostly
did those for completeness atm and proof of concept.

I'll work on a proper RFC in the next day or so for sure.

Chuck


On Tue, 2008-10-14 at 16:02 -0400, Frank Warmerdam wrote:
> >> On Tue, Oct 14, 2008 at 11:12 AM, Chuck Thibert
> >> <charles.thibert at ingres.com> wrote:
> >>> Hi,
> >>>
> >>> I have been prototyping a thread safe CAPI.  I have attached a simple
> >>> proposal/design intent.  I have sample executables and test data that
> >>> will illustrate the thread issues but I don't want to flood the mailing
> >>> list with them.  If the proposal attached looks decent to you all I'll
> >>> create a new ticket and attach the code I have to that.
> 
> Chuck,
> 
> As defined, the GEOSHandle structure is public.  This means any change
> in the layout or items in the GEOSHandle structure cannot be changed
> without altering the ABI.
> 
> I would like to suggest altering the approach so that the structure
> structure is allocated internally by initGEOS_TS() and only an opaque
> handle would be returned.
> 
> eg.
> 
>    typedef void *GEOSHandle_t;
> 
>    GEOSHandle_t initGEOS_TS( GEOSMessageHandler notice_function,
>                              GEOSMessageHandler error_function);
> 
>    void finishGEOS_TS( GEOSHandle_t *handle );
> 
> I think we should also at this point consider whether there is anything
> else that we want to be able to control on a per-thread-context basis.
> For instance, currently the C API only offers use of the default
> geometry factory.  Would there be reasons to provide access to others?
> Also, given recent discussions, allowing overloading of the memory
> allocator might be of interest.
> 
> I'm quite supportive of this thread safety change, and the approach
> seems quite practical. I'd like to see a "proper" RFC written up in
> Trac and voted on.
> 
> PS. It isn't very important, but I think a name like GEOSContext_t
> or even GEOSContextHandle_t would be better than GEOSHandle_t.  The
> object is essentially an execution context/environment.
> 
> PPS. I'm not sure why there are GEOSversion_TS() and GEOS_jtsport_TS()
> function that operate exactly like the non-TS version. I'd like to
> suggest we only implement _TS() versions of function that need the
> handle/context to operate.
> 
> Best regards,