FYI, I finally committed the code installing a signal handler in PostGIS,
using the pqsignal function:
https://trac.osgeo.org/postgis/changeset/9850
It is currently only used to interrupt GEOS calls, but the idea is that
it could eventually also be used to interrupt other library calls having
a provision for such interruption request. GEOS itself only supports it
in the 3.4 branch.
In order to test it you'll need to define POSTGIS_ENABLE_GEOS_INTERRUPTIBILITY
at the top of postgis/postgis_module.c - the macro is off by default due
to concerns about possible consequences we may be unaware of.
Your comments will be very useful to reduce (or confirm) the concerns.
If we can get this confidently straight there may be the possibility to
toggle the default to on before 2.0.1 ...
Thanks in advance.
PS: Tom, I still don't know what you mean by "the SIGINFO case".
--strk;
On Mon, May 28, 2012 at 08:48:21AM +0200, Sandro Santilli wrote:
> On Fri, May 25, 2012 at 12:34:54PM -0400, Tom Lane wrote:
> > Sandro Santilli <strk@keybit.net> writes:
> > > I ended up providing an explicit mechanism to request interruption of
> > > whatever the library is doing, and experimented (successfully so far)
> > > requesting the interruption from a SIGINT handler.
> >
> > > Do you see any major drawback in doing so ?
> >
> > This seems a bit fragile. It might work all right in Postgres, where
> > we tend to set up signal handlers just once at process start, but ISTM
> > other systems might assume they can change their signal handlers at
> > any time. The handler itself looks less than portable anyway ---
> > what about the SIGINFO case?
>
> Indeed setting the handler from within the library itself was a temporary
> implementation to see how effective it would have been. The idea is to
> move the registration of the hanlder outside the library and into the
> user (PostGIS in this case). The library itself would only expose
> GEOS_requestInterrupt/GEOS_cancelInterrupt API calls.
>
> I'm guessing PostGIS should use the more portable pqsignal functions ?
>
> What should I know about SIGINFO ?
>
> > I assume that the geos::util::Interrupt::request() call sets a flag
> > somewhere that's going to be periodically checked in long-running
> > loops.
>
> Yes, this is what will happen.
>
> > Would it be possible for the periodic checks to include a
> > provision for a callback into Postgres-specific glue code, wherein
> > you could test the same flags CHECK_FOR_INTERRUPTS does? A similar
> > approach might then be usable in other contexts, and it seems safer
> > to me than messing with a host environment's signal handling.
>
> Would it be enough for the signal handler (installed by PostGIS)
> to check those flags and call the GEOS_requestInterrupt function
> when appropriate ?
>
> --strk;
