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

From Sandro Santilli
Subject Re: Interrupting long external library calls
Date
Msg-id 20120524141410.GC17214@gnash
Whole thread Raw
In response to Re: Interrupting long external library calls  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-hackers
On Thu, May 24, 2012 at 04:55:34PM +0300, Heikki Linnakangas wrote:
> On 24.05.2012 16: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 ?
> 
> It would only be safe to call it in places where no cleanup is
> necessary. I don't know if there are any such places in the geos
> library.

Sure, right before starting and after finishing.
That is nowhere useful for a premature interruption...

The whole point of the work I'm doing these days is letting the
users interrupt GEOS calls which often take a long time and a lot
of memory resources.

The current plan is to provide custom allocators to have automatic
garbage collection on interruption. Turned out not to be an easy task
to bend GEOS into using palloc/pfree, but there's progress in that
direction.

--strk;


pgsql-hackers by date:

Previous
From: Joachim Wieland
Date:
Subject: Re: "could not open relation with OID" errors after promoting the standby to master
Next
From: Marko Kreen
Date:
Subject: [9.2] crash on regex