After the bloody fight with custom memory allocators I decided to change strategy and approached explicit support in GEOS for interruption requests and a signal handler to trigger it.
It proves effective and much cleaner so far. I've been testing it by installing an handler for SIGINT straight into GEOS itself, but I understand that's not a clean way to do it so before committing I will port the code into PostGIS itself. On the GEOS side this is another C-API extension, whereas we'll have GEOS_requestInterrupt() and GEOS_cancelInterrupt() functions usable from the outside. The functions will set or clear a flag that will be explicitly checked within the GEOS C++ codebase at places which are known to be possibly iterated significatively. Presence of the flag would result in an exception being thrown, which should supposedly give GEOS all it takes to perform any appropriate cleanups. If you want to test the handler-in-geos implementation (which has the advantage of working with _any_ PostGIS version) you can do so using this experimental branch: git pull git://github.com/strk/libgeos.git svn-trunk-interruptable The handler is installed on first call to initGEOS time. I actually wonder if I should just keep the handler in there... --strk; ,------o-. | __/ | Delivering high quality PostGIS 2.0 ! | / 2.0 | http://strk.keybit.net - http://vizzuality.com `-o------' _______________________________________________ geos-devel mailing list geos-devel@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/geos-devel
