[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Control plane/Data plan communication using file
From: |
Eric Blossom |
Subject: |
Re: [Discuss-gnuradio] Control plane/Data plan communication using file descriptors |
Date: |
Mon, 21 Aug 2006 12:26:03 -0700 |
User-agent: |
Mutt/1.5.9i |
On Mon, Aug 21, 2006 at 08:39:05AM -0700, Johnathan Corgan wrote:
> '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.
The pipe part of it sucks, but the idea seems to hold up pretty well.
Other code (fftsink, scopesink) has been re-written to use
gr_messages and gr_msg_queue, which work independent of the underlying OS.
> 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.
Use messages and message queues. They are thread safe and are
designed specifically to solve this problem.
You can look at fftsink.py or the
gnuradio-core/src/python/gnuradio/blksimpl/pkt.py for examples.
> Aside from select not working with pipes on Win32, does this seem like a
> good application structure?
See above ;)
> How have people dealt with the separation of user interface and data
> flow in a scalable way?
See above ;)
The mblock stuff under developement will provide a similar approach
using messages to communicate between interested parties. In
addition, since _all_ communication is message based, it eliminates
the inter-thread data access problem (actually it puts all "behind the
scenes" where it can be taken care of in one place by the underlying
runtime system).
> -Johnathan (wanting to think about something besides autotools!)
I can imagine ;)
Eric