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 > >> <[EMAIL PROTECTED]> 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, _______________________________________________ geos-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/geos-devel
