On 25 May 2012 17:34, Tom Lane <tgl@sss.pgh.pa.us> 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?
>
> I assume that the geos::util::Interrupt::request() call sets a flag
> somewhere that's going to be periodically checked in long-running
> loops. 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.
Can we do that as a macro, e.g.
POSTGRES_LIBRARY_INTERRUPT_CHECK()
Otherwise the fix to this problem may be worse - faulty interrupt
handlers are worse than none at all.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services