discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

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