On Jun7, 2012, at 12:08 , Sandro Santilli wrote:
> On Thu, Jun 07, 2012 at 12:00:09PM +0200, Florian Pflug wrote:
>> On Jun7, 2012, at 10:20 , Sandro Santilli wrote:
>
>>> In that case I can understand Tom's advice about providing a callback,
>>> and then I would only need to perform the "events
On Thu, Jun 07, 2012 at 12:00:09PM +0200, Florian Pflug wrote:
> On Jun7, 2012, at 10:20 , Sandro Santilli wrote:
> > 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 onl
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 wrote:
I assume that the geos::util::Interrupt::request() call sets a flag
somewhere that'
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 wrote:
> >> I assume that the geos::util::Interrupt::request() call sets a flag
> >> somewhere that's going to be periodically checked in long-running
>
FYI, I finally committed the code installing a signal handler in PostGIS,
using the pqsignal function:
https://trac.osgeo.org/postgis/changeset/9850
It is currently only used to interrupt GEOS calls, but the idea is that
it could eventually also be used to interrupt other library calls having
a
On Fri, May 25, 2012 at 12:34:54PM -0400, Tom Lane wrote:
> Sandro Santilli writes:
> > 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 y
On May26, 2012, at 12:40 , Simon Riggs wrote:
> On 25 May 2012 17:34, Tom Lane 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
>>
On 25 May 2012 17:34, Tom Lane wrote:
> Sandro Santilli writes:
>> 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 drawbac
Sandro Santilli writes:
> 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 ?
This seems a bit fragile. It
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
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 ?
>>
>>
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 ther
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_I
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 InterruptPendi
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
On Wed, May 16, 2012 at 02:46:17PM +0300, Heikki Linnakangas wrote:
> On 16.05.2012 14:30, Mark Cave-Ayland wrote:
> >On 16/05/12 11:39, Heikki Linnakangas wrote:
> >
> >>However, if you're absolutely positively sure that the library function
> >>can tolerate that, you can set "ImmediateInterruptOK
On 16.05.2012 14:30, Mark Cave-Ayland wrote:
On 16/05/12 11:39, Heikki Linnakangas wrote:
However, if you're absolutely positively sure that the library function
can tolerate that, you can set "ImmediateInterruptOK = true" before
calling it. See e.g PGSemaphoreLock() on how that's done before s
On 16/05/12 11:39, Heikki Linnakangas wrote:
One of the issues we've been looking at with PostGIS is how to interrupt
long-running processing tasks in external libraries, particularly GEOS.
After a few tests here, it seems that even the existing SIGALRM handler
doesn't get called if statement_ti
On 16.05.2012 13:25, Mark Cave-Ayland wrote:
One of the issues we've been looking at with PostGIS is how to interrupt
long-running processing tasks in external libraries, particularly GEOS.
After a few tests here, it seems that even the existing SIGALRM handler
doesn't get called if statement_tim
Hi all,
One of the issues we've been looking at with PostGIS is how to interrupt
long-running processing tasks in external libraries, particularly GEOS.
After a few tests here, it seems that even the existing SIGALRM handler
doesn't get called if statement_timeout is reached when in an externa
20 matches
Mail list logo
