From ustaudinger at activequant.com  Mon Nov 26 09:21:46 2012
From: ustaudinger at activequant.com (Ulrich Staudinger)
Date: Mon, 26 Nov 2012 09:21:46 +0100
Subject: [Rd] Sighandlers
In-Reply-To: <50A8EDE6.7080005@stats.ox.ac.uk>
References: <CAMrz3D0MNwuiYRiqGWOh8AAT6rcdAbppi9BDZ9EvqqDiSdQ8_Q@mail.gmail.com>
	<50A8EDE6.7080005@stats.ox.ac.uk>
Message-ID: <CAMrz3D210akMXL--4osYXQsSz59F9EzZBMLrwGafT-7gw00HSA@mail.gmail.com>

Hello there,

On Sun, Nov 18, 2012 at 3:17 PM, Prof Brian Ripley
<ripley at stats.ox.ac.uk> wrote:
> R has its own signal handlers, including for SIGINT.
>
> What is your 'extension'?   If it is a program embedding R, the order of
> setting signal handlers will matter, and in any case R's handler if ever
> called it will reset the handler to itself.

The extension does open a socket connection to some distant server. It
serves as a data buffer, from where the R-main thread may poll data.

> If it is a package, it should not be messing with the process into which it
> is loaded.

This is entirely clear.

In this particular case, I used fork() to fork off a new process. For
obvious reasons, this process stayed alive beyond the R-session.  In
other words, I terminated R and my forked off process continued
running. The natural approach would be to register a sighandler and
get notified about R's termination, so that the afore mentioned
buffering process may terminate gracefuly, too.

I solved it by using pthreads rather than fork(), as the pthread is
attached to a parent process and will terminate with it.

>
> On 17/11/2012 15:56, Ulrich Staudinger wrote:
>>
>> Hello everyone,
>>
>> I am searching and searching and can't find an answer.
>
>
> Did you search the source code?

That's a bit beyond me at the moment.


Thanks,
Ulrich






-- 
Ulrich Staudinger

P: +41 79 702 05 95
E: ustaudinger at activequant.com

http://www.activequant.com
Connect online: https://www.xing.com/profile/Ulrich_Staudinger



[Rd] Sighandlers
Ulrich Staudinger