[postgis-devel] New strategy for GEOS interruptability

[Sandro Santilli]

After more and more testing I find the experiemental approach
actually pretty effective. So much that I'm wondering why not
using it straight away in GEOS-3.3.4 (to be shipped shortly,
coupled with PostGIS-2.0.1).

By requiring NO change in the GEOS-C-API interface (as long as
the SIGINT handler is installed on initGEOS) we don't need to
bump up the GEOS minor version. And the mechanism needs NO
change in PostGIS in order to work.

My only concern is portability of the code installing the signal
handler. 

Anyone up for testing this on MacOS and Win32/65 ?

--strk;

On Fri, May 25, 2012 at 02:42:23PM +0200, Sandro Santilli wrote:
> 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;