[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Control plane/Data plan communication using filed
Re: [Discuss-gnuradio] Control plane/Data plan communication using filedescriptors
Mon, 21 Aug 2006 12:16:17 -0400
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
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
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
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
-- Don Ward
----- Original Message -----
From: "Johnathan Corgan" <address@hidden>
Sent: Monday, August 21, 2006 11:39 AM
Subject: [Discuss-gnuradio] Control plane/Data plan communication using
'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
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