[geos-devel] RFC for Thread safe CAPI announced

[Mark Cave-Ayland]

> 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.

Heh, of course ;)

Well the definition is fairly woolly as a quick search revealed that the
distinction between thread safety and re-entrancy is not always apparent
in various descriptions of the functions. Probably the best descriptions I
found were here:

http://publib.boulder.ibm.com/infocenter/systems/index.jsp?topic=/com.ibm.aix.genprogc/doc/genprogc/writing_reentrant_thread_safe_code.htm
http://www.ibm.com/developerworks/linux/library/l-reent.html

These basically describe a re-entrant function as one that does not hold
static data across successive calls, or return a pointer to static data.
So you could argue that since the static data will be held outside of the
function (and it is not modified by the function) then it is re-entrant
and thus qualifies for the _r suffix.

Then again, I will confess up front that I don't do much in the way of
multi-threaded programming and so this was just my interpretation of the
above and other random sources located using Google.


ATB,

Mark.