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,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
_______________________________________________
geos-devel mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/geos-devel
