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