Re: [Discuss-gnuradio] Control plane/Data plan communication using filedescriptors

[Don Ward]

You may lose many of your Windows/MinGW customers if you use pipes.
Pipes on Windows will only work if gnuradio and Python can agree on
which version of the C runtime library to use.  Because the binary 
distribution
of Python 2.4 for Windows is compiled with Microsoft's VC 7 and uses the
msvcr71.dll, pipes in gnuradio will only work if it is also compiled with 
the
same Microsoft compiler.  The choices are (1) get a Microsoft compiler,
(2) go back to Python 2.3,  (3) try to build Python from source using gcc,
or (4) make MinGW use a different C library (e.g., msvcr71.dll).
I'm not doing (1).  Does anyone know if gnuradio has any problem with
Python 2.3?  (3) may be difficult, since the Python build process for
Windows is likely geared to using the Microsoft tools.  I've seen hints that
(4) may be possible, but I don't think the process is documented or 
supported.

An alternative for Windows users is to use Cygwin.  I am currently working
on this and all seems to be going well, but I haven't yet tackled to problem 
of
building wxPython.

-- Don Ward

----- Original Message ----- 
From: "Johnathan Corgan" <address@hidden>
To: <address@hidden>
Sent: Monday, August 21, 2006 11:39 AM
Subject: [Discuss-gnuradio] Control plane/Data plan communication using 
filedescriptors


> 'waterfallsink.py' uses pipes as an IPC mechanism to get data from one
> thread (running gnuradio dispatch loop) to another thread (running
> wxPython's dispatch loop), by creating a pipe and using
> file_descriptor_sink/source to move the data.
>
> This seems to be a good way to do things, and I'd like to see how well
> it fits in a more general case.
>
> One could implement the 'data plane' of one's application as a set of
> gnuradio blocks that implement all the signal processing, and have a set
> of pipes that output various display updates.  The user interface code
> could select() on these pipes and handle updating the various GUI
> elements after reading the available data.
>
> For control, having the GUI code invoke public methods on the gnuradio
> blocks seems ok, bearing in mind any inter-thread data access locking
> required.
>
> Aside from select not working with pipes on Win32, does this seem like a
> good application structure?
>
> How have people dealt with the separation of user interface and data
> flow in a scalable way?
>
> -Johnathan (wanting to think about something besides autotools!)
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio