Re: Interrupting long external library calls

On Sat, May 26, 2012 at 01:24:26PM +0200, Florian Pflug wrote:
> On May26, 2012, at 12:40 , Simon Riggs wrote:
> > On 25 May 2012 17:34, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> 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.
>
> As it stands, ProcessInterrupts() sometimes returns instead of
> ereport()ing even if InterruptPending is set, interrupts aren't
> held off, and the code isn't in a critical section. That happens if
> QueryCancelPending (or however that's called) gets reset after a
> SIGINT arrived but before CHECK_FOR_INTERRUPTS() is called. Or at
> least that is how I interpret the comment at the bottom of that
> function...
>
> We could thus easily provide POSTGRES_LIBRARY_INTERRUPT_CHECK() if
> we're content with the (slim, probably) chance of false positives.
>
> Or we'd need to refactor things in a way that allows the hypothetical
> POSTGRES_LIBRARY_INTERRUPT_CHECK() to re-use the tests in
> ProcessInterrupts(), but without modifying any of the flags.

So back to this, shortly after discovering (sorry for ignorance, but I
just don't care about programming in a black box environment) that windows
doesn't support posix signals.

If I understood correctly the CHECK_FOR_INTERRUPTS postgresql function
does also take care of events dispatching within windows, so that if
nothing calls that macro there's no way that a "pqsignal" handler would
be invoked. Is that right ?

In that case I can understand Tom's advice about providing a callback,
and then I would only need to perform the "events flushing" part of
from within the callback, and only for windows.

Does it sound right ?

--strk;