discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] gr.file_sink() or connect() limitations?


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] gr.file_sink() or connect() limitations?
Date: Fri, 6 Mar 2009 10:18:50 -0800
User-agent: Mutt/1.5.18 (2008-05-17)

On Thu, Mar 05, 2009 at 10:35:37PM -0800, Francesco B. wrote:
> 
> Below is a short GNU Radio pipeline. Its purpose is to write an impulse
> response to a character device node representing an FPGA (which contains a
> 4-coefficient lowpass filter), read the FPGA's output, and store said output
> in a file. 

FWIW, the comment about os.fork() concerns me.  If you are expecting
both parent and child to continue running GNU Radio code after
os.fork, you have a misunderstanding of our code, and possibly of fork
in general. (I'm not certain that this is what you're trying to do,
but if it is, it won't work.)  There's a bunch of shared state behind
the scenes that will end up "copy-on-write" after fork, leaving the
no-longer-shared state inconsistent.  A standalone call to fork is
almost never the answer to any problem.  If you're trying to run an
external program from within python, consider using os.system or
os.popen.

> At least, it'd be appreciated if someone could point me to the code for
> gr.file_sink() itself. I get lost in the mass of processing blocks that make
> use of it when I try to search for it, and can't find the file_sink() block
> itself.

Using common command line tools will allow you to find the source for
any block.  E.g.,

  $ find . -print | grep -v \.svn | xargs grep -l file_sink


  ./gnuradio-core/src/lib/io/gr_file_sink.h
  ./gnuradio-core/src/lib/io/gr_file_sink_base.cc


The etags and/or ctags command are helpful too.

  $ man ctags

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]