On 29/01/13 10:29, Mark Kirkwood wrote:
> On 25/01/13 13:56, Mark Kirkwood wrote:
>> On 25/01/13 13:49, Tom Lane wrote:
>>> Mark Kirkwood <mark.kirkwood@catalyst.net.nz> writes:
>>>> On 25/01/13 13:06, Tom Lane wrote:
>>>>> Unless libR can be coerced into not screwing up our signal handlers,
>>>>> I'd say that PL/R is broken beyond repair. That would be
>>>>> unfortunate.
>>>
>>>> It looks like Joe has run into something similar with libR stealing
>>>> SIGINT, he reinstalls it. A simple patch along the same lines for
>>>> SIGUSR1 (attached) seems to fix the issue.
>>>
>>> This certainly is not good enough, for either signal. What happens if
>>> the signal arrives while libR still has control? These things being
>>> asynchronous with respect to the receiving backend, we certainly can't
>>> assume that that won't happen.
>>>
>>> Why does libR think it should be messing with these handlers in the
>>> first place?
>>>
>>>
>>
>> Agreed - I will see if I can work out why.
>>
>
>
> Looking at the R source (which reminds me of Postgres, nice, clear
> code...), I saw quite a bit of code involving signal handlers - and
> nothing along the lines of "don't set them up if you are in embedded
> mode". So clearly more investigation is needed, and we really need to
> take this up on the R mailing list I think. Joe - is this something
> you would like to do? I am happy do it, but my knowledge of R is
> measured in hours...
>
>
Like a dog with a bone - sometimes it's hard to let go... given the
quite readable nature of the R source I managed to find what I *think*
is the "don't do R signals switch" (which I'd obviously missed before).
Making use of this seems to fix the original bug - and possibly the
SIGINT stealing too.
Patch attached to set the variable (R_SignalHandlers = 0), and remove
the SIGINT workaround.
Cheers
Mark