Re: Interrupting long external library calls

On Jun7, 2012, at 10:20 , Sandro Santilli wrote:
> 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 ?

Yes.

> 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.

Why would you need a signal handler in the library at all, then? Just
test the same flags that CHECK_FOR_INTERRUPTS does in the callback, and
call your interrupt request method if they indicate "abort". (Or, slightly
cleaner maybe, allow the callback to abort processing by returning false)

best regards,
Florian Pflug