Re: Interrupting long external library calls

From: Sandro Santilli <strk(at)keybit(dot)net>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Mark Cave-Ayland <mark(dot)cave-ayland(at)ilande(dot)co(dot)uk>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interrupting long external library calls
Date: 2012-05-25 16:06:34
Message-ID: 20120525160634.GP27878@gnash
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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------'

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2012-05-25 16:13:32 Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Previous Message Jeff Janes 2012-05-25 15:53:45 Re: pg_dump and thousands of schemas