Re: Interrupting long external library calls
От | Heikki Linnakangas |
---|---|
Тема | Re: Interrupting long external library calls |
Дата | |
Msg-id | 4FBE3DD6.7070305@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Interrupting long external library calls (Sandro Santilli <strk@keybit.net>) |
Ответы |
Re: Interrupting long external library calls
|
Список | pgsql-hackers |
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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: