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;
,------o-. | __/ | Delivering high quality PostGIS 2.0 ! | / 2.0 | http://strk.keybit.net -
http://vizzuality.com`-o------'
