Re: Interrupting long external library calls - Mailing list pgsql-hackers

From Sandro Santilli
Subject Re: Interrupting long external library calls
Date
Msg-id 20120525160634.GP27878@gnash
Whole thread Raw
In response to Re: Interrupting long external library calls  (Florian Pflug <fgp@phlo.org>)
Responses Re: Interrupting long external library calls
List pgsql-hackers
On Thu, May 24, 2012 at 04:37:04PM +0200, Florian Pflug wrote:
> On May24, 2012, at 15:04 , Sandro Santilli wrote:
> > On Wed, May 16, 2012 at 07:30:03PM +0300, Heikki Linnakangas wrote:
> >> On 16.05.2012 15:42, Sandro Santilli wrote:
> >>> But CHECK_FOR_INTERRUPTS doesn't return, right ?
> >>> Is there another macro for just checking w/out yet acting upon it ?
> >> 
> >> Hmm, no. CHECK_FOR_INTERRUPTS() checks the InterruptPending
> >> variable, but on Windows it also checks for
> >> UNBLOCKED_SIGNAL_QUEUE(). And even if InterruptPending is set, it's
> >> not totally certain that CHECK_FOR_INTERRUPTS() won't return. I
> >> think InterruptPending can be set spuriously (even if that's not
> >> possible today, I wouldn't rely on it), and if you're in a
> >> HOLD/RESUME_INTERRUPTS block, CHECK_FOR_INTERRUPTS() will do nothing
> >> even if InterruptPending is true.
> >> 
> >> The only sane way to make 3rd party code interruptible is to add
> >> CHECK_FOR_INTERRUPTS() to it, in safe places.
> > 
> > No place is safe if CHECK_FOR_INTERRUPTS doesn't return.
> > How could caller code cleanup on interruption ?
> 
> The postgres way is to use PG_TRY/PG_CATCH to make sure stuff gets cleaned
> up if an error or an interrupts occurs. You could use those to make the
> third-party library exception safe, but it'll probably be a quite
> invasive change :-(.
> 
> Alternatively, you could replicate the check CHECK_FOR_INTERRUPTS() does,

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 ?

So far I installed the SIGINT handler within the library itself, but
I guess it could be moved out instead to have ore fine-grained control
over when to request interruption.

Here's the code installing the signal handler within the library:
https://github.com/strk/libgeos/commit/e820ecd0469b777953c132661877c2967b10cee2

--strk; 
 ,------o-.  |   __/  |    Delivering high quality PostGIS 2.0 ! |  / 2.0 |    http://strk.keybit.net -
http://vizzuality.com`-o------'
 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Next
From: Merlin Moncure
Date:
Subject: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile