[geos-devel] RFC for Thread safe CAPI announced

[Chuck Thibert]

Thanks for the comments again Frank.  I appreciate the time put into
reviewing this.

I'll illustrate the handle better.  I was thinking along the same lines
as you were, just assuming too much and not specifying.

I was assuming the pointer being passed to initGEOS would be empty and
allocated by initGEOS.  Probably just me being more used to passing
variables to be allocated instead of returning them.  I'm not opposed to
the way you have it and will update it.

The _r was a comment from Mark Cave-Ayland.  I agree it usually means
re-entrant.  I've been torn on how to name this as I'm not going for
re-entrancy but it is 'more standard.'  Mark, it was your comment,
rebuttal? :) Otherwise I think I'll go back to TS since I'm not
guaranteeing re-entrance.

Thanks,
Chuck


On Fri, 2008-10-17 at 15:06 -0400, Frank Warmerdam wrote:
> Chuck Thibert wrote:
> > RFC updated.
> > 
> 
> Chuck,
> 
> I notice that the application still needs to pass a pointer to a
> GEOSContextHandle_t structure into initGEOS_r() instead of having
> initGEOS_r() allocate the structure internally.  Was there a reason for
> this?  As I mentioned before, I think this makes the interface brittle
> in the sense that the application code has to be recompiled any time
> the contents of the context structure change.  My suggested alternative
> is:
> 
>    GEOSContextHandle_t initGEOS_r( GEOSMessageHandler notice_function,
>                                    GEOSMessageHandler error_function);
> 
> I'd add that I'd like the RFC to define the context of the context
> structure.  I also think that the application visible handle should be
> declared:
> 
>    type void *GEOSContextHandle_t;
> 
> so that it would be passed around as a value rather than a pointer.  This
> isn't really very important, but I think it makes the opaqueness of the
> handle clearer.  This is the same model used by all the handles for objects
> in the GDAL and OGR C APIs for instance.
> 
> Last, I *think* that the _r appended to some C library functions implies
> reentrancy, while I think this RFC aimed only at thread-safety.  If that
> is the case the original idea of appending _TS might be better than _r to
> avoid fooling people into thinking the C API is reentrant (that is that
> multiple threads could operate on the same context at the same time).
> 
> Best regards,