Re: [geos-devel] deprecate non-thread-safe CAPI interfaces
On Wed, Feb 10, 2010 at 09:42:56PM -0600, Howard Butler wrote: On Feb 10, 2010, at 5:26 PM, strk wrote: I'd like to deprecate non-thread-safe version of CAPI interface in next release, and stop providing them for new methods. If anyone sees a reason not to do that please scream before it's too late (you've plenty of time). The proposal would be to stop providing new methods and method updates for the non-thread-safe API, correct? What I mean is that when *new* interfaces are added, only the version taking GEOSContextHandler would be provided. And (I meant) all other ones not taking that handler would be marked with deprecated attribute so warnings come out at build time (only for GCC I know how..). Can still wait for the second part (deprecation), but I think it makes sense for the first part (stop *adding* the bare ones). --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] deprecate non-thread-safe CAPI interfaces
I'd like to deprecate non-thread-safe version of CAPI interface in next release, and stop providing them for new methods. If anyone sees a reason not to do that please scream before it's too late (you've plenty of time). --strk; () Free GIS Flash consultant/developer /\ http://foo.keybit.net/~strk/services.html ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] deprecate non-thread-safe CAPI interfaces
On Feb 10, 2010, at 5:26 PM, strk wrote: I'd like to deprecate non-thread-safe version of CAPI interface in next release, and stop providing them for new methods. If anyone sees a reason not to do that please scream before it's too late (you've plenty of time). The proposal would be to stop providing new methods and method updates for the non-thread-safe API, correct? While I'm generally in support of this, I think it is one release too early. I think that people are just now undertaking the development efforts to use the thread safe API in their software, and we should give folks a bit more time before we pull the rug out. Let's wait until 3.4 instead of doing it in 3.3. Howard ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] deprecate non-thread-safe CAPI interfaces
On Wed, 10 Feb 2010, Howard Butler wrote: On Feb 10, 2010, at 5:26 PM, strk wrote: I'd like to deprecate non-thread-safe version of CAPI interface in next release, and stop providing them for new methods. If anyone sees a reason not to do that please scream before it's too late (you've plenty of time). The proposal would be to stop providing new methods and method updates for the non-thread-safe API, correct? While I'm generally in support of this, I think it is one release too early. I think that people are just now undertaking the development efforts to use the thread safe API in their software, and we should give folks a bit more time before we pull the rug out. Let's wait until 3.4 instead of doing it in 3.3. My understanding is that MSYS builds for Win 32 (and maybe 64) do not have or use pthreads. R is not thread safe and will never be (compute threads are handled differently by say threaded BLAS or coarse-grained partition of tasks into sections for parallel computation). I think that GDAL provides a MUTEX_NONE stub which I see kicking in on MSYS. On Linux and OSX, this probably isn't an issue, but building static GEOS for Windows necessarily using the R build train (MinGW, MSYS) is fragile, and could be broken by hasty changes. The potential R install base for GEOS functionality is at least in the thousands, mostly Windows users (sorry), who rely on the developers providing packaged binaries through CRAN. If you could push this a little forward in time, and let me try with the development version to make sure that any transition can be managed, I'd be grateful. As I've said before, the motivation for rgeos is to provide an alternative to non-free GPC that has been interfaced to R. I realise that GEOS usually goes in at the base of the software stack, and usually interfaces GIS-type systems, so this case is somewhat atypical. Roger Howard ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel -- Roger Bivand Economic Geography Section, Department of Economics, Norwegian School of Economics and Business Administration, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43 e-mail: roger.biv...@nhh.no ___ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
