Re: [Discuss-gnuradio] Linux signals and forks in GnuRadio

[Eric Blossom]

On Fri, May 09, 2008 at 10:35:17AM -0400, Ed Criscuolo wrote:
> Are there any special considerations needed to use Linux signals
> (in particular sigalarm) or forks from within a custom GnuRadio
> C++ block?
>
>
> Background information:
>
> I'm written a block that consumes an HDLC/MPoFR bitstream and
> extracts and forwards any contained IP packets.  The block
> generates a number of data and error statistics which I would
> like to periodically send to another system via a UDP packet,
> at a rate which is unrelated to the block's sample rate.
> My thought is to use alarm() to generate a sigalarm every
> reporting interval, and register a private method as the
> signal handler.  If the reporting ends up taking too long,
> I would use a fork from within the signal handler and do
> the reporting in the child process.
>
> Is this approach workable within the GnuRadio framework?
> Or are there interactions with the scheduler and/or the
> use of threads that render it unworkable or unreliable?
>
> Thanks in advance!

Hi Ed,

I'd stay away from signals and alarm.  I think a "more likely to work
now and in the future" approach is to have the time keeping happen in
python, possibly in another thread, and have it call a method on your
class when it's time to extract the results and send them via UDP.

FWIW, theads and signals are a fairly nasty combination.  As you've
probably noticed, there's only a single signal handler for all
threads, though you can mask which signals a given thread sees.
With the multi-processor (MP) scheduler I'm currently working on,
you'll never know what thread could to executing any given block at
any given time.

Eric