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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
