W dniu 26.03.2015 o 08:39, Piotr Krysik pisze: > W dniu 25.03.2015 o 16:48, Tom Rondeau pisze: >> On Wed, Mar 25, 2015 at 3:11 AM, Piotr Krysik <per...@o2.pl >> <mailto:per...@o2.pl>> wrote: >> >> W dniu 16.02.2015 o 17:29, Tom Rondeau pisze: >> > On Sat, Feb 14, 2015 at 3:34 PM, Piotr Krysik <per...@o2.pl >> <mailto:per...@o2.pl> >> > <mailto:per...@o2.pl <mailto:per...@o2.pl>>> wrote: >> > >> > W dniu 29.04.2014 o 16:20, Tom Rondeau pisze: >> > > On Tue, Apr 29, 2014 at 9:33 AM, Perper <per...@o2.pl >> <mailto:per...@o2.pl> <mailto:per...@o2.pl <mailto:per...@o2.pl>> >> > > <mailto:per...@o2.pl <mailto:per...@o2.pl> >> <mailto:per...@o2.pl <mailto:per...@o2.pl>>>> wrote: >> > > >> > > Hi all, >> > > >> > > I want to use message passing blocks for operations >> where strict >> > > synchronization is not necessary. However in flowgraphs >> > using message >> > > passing with "Run to completion" option turned on the >> > program doesn't >> > > exit on last processed sample. Is this a bug? >> > > >> > > I want to use message passing in my programs (mainly in >> > > https://github.com/Jakotako/gr-gsm) but completion after >> > processing of >> > > all input data is also very important for me. >> > > >> > > -- >> > > Piotr Krysik >> > > >> > > >> > > >> > > Yes, this is a known issue and we are working on it. >> > > >> > > Tom >> > > >> > Hi Tom, >> > >> > In GNU Radio 3.7.6 this is still an issue. It's quite >> serious because >> > whole class of applications that would use message passing >> and rely on >> > the processing in the flowgraph to end after processing of chunk >> > of the >> > signal (i.e. to change the flowgraph in known conditions) is not >> > possible. >> > >> > I'm working on a simple gsm network monitor application based on >> > gr-gsm >> > (https://github.com/ptrkrysik/gr-gsm) and have quite hard >> time because >> > of this issue. >> > >> > Is this some general problem where the source of it is that >> GNU Radio >> > was meant primarily to process stream of samples? Or is it some >> > simpler >> > matter? >> > >> > I've attached vary simple flowgraph that demonstrates the >> problem. >> > >> > Best Regards, >> > Piotr Krysik >> > >> > >> > The fix for this was pushed a couple of weeks ago and will make >> it in >> > the 3.7.7 release. We're looking to see any side effects and >> might be >> > able to back-port it for the next 3.7.6 maint release. Commit here: >> > >> > >> >> https://github.com/gnuradio/gnuradio/commit/035b9d016dffefec890323bd0b24dbaf23aa9186 >> > >> > Tom >> > >> >> I've tied gnuradio compiled with and without this commit. I didn't >> observe difference - run to completion doesn't seem to work with >> message >> passing. I've attached the gnuradio-companion flowgraph that I've used >> for the test. >> >> Question to the list: does "Run to completion" feature work for you in >> the attached example or in any other case of a flowgraph with message >> passing? >> >> -- >> Piotr >> >> >> Ah, well there's the problem. In GRC open up "Help"->"Types". The >> blocks you are using are the old Message Queue based blocks, not the >> new asynchronous message passing interface. The commit that I was >> talking about was specific to the async message passing, so yeah, it'd >> have no bearing on this. >> >> This is definitely confusing since they are both "message" based even >> though it's a completely different system. The old style used here >> will likely be removed at some point, though it's use persists in a >> few places. For your stuff, I'd avoid using this (anything with that >> dark grey port) and use the new async messages (the light grey ports). >> >> Tom >> > Tom, > > The attached flowgraph was an example. I wanted to prepare something > small that uses only GNU Radio's message blocks, to avoid situation > where I messed something in C++. The blocks that I selected were not > appropriate for the situation. > > However in > https://github.com/ptrkrysik/gr-gsm/blob/master/apps/airprobe_file.grc > I'm using only message passing interface, but can't get "Run to > completion" to work as it should. > > Can you show an example of GRC flowgraph that uses message passing and > exit when the input signal is over? I would greatly appreciate that as > I'm a little bit stuck on this problem. > > -- > Piotr > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > Hi,
Yesterday funkylab adviced me to debug the issue using GDB. The description of the method in his own words: 1. rerun cmake with -DCMAKE_BUILD_TYPE=RelWithDebInfo 2. rebuild and install gr-gsm 3. load the right stuff into gdb: gdb --args python apps/airprobe_rtlsdr.py gdb will load up type run the flow graph will start to execute now, we expect it to shut down instead, parts of it continue to run, but we don't know which, right? so at some point you just hit ctrl+z in gdb now you're at the gdb prompt again info threads will show you the threads that are still active. If you built GNU Radio with debug info too (see the cmake thing above), you will have threads with names that look like blocks I did that and what I obtained was: --------------------------------------------------------------------------------------- 16 Thread 0x7fffbdffb700 (LWP 13462) "python" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 3 Thread 0x7fffe9720700 (LWP 13449) "gsm_clock_offs1" pthread_cond_timedwait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:238 * 1 Thread 0x7ffff7fc7740 (LWP 13444) "python" 0x00007ffff78e8da3 in select () at ../sysdeps/unix/syscall-template.S:81 --------------------------------------------------------------------------------------- One of the threads indicates that clock_offset_control block didn't end as it should. So I disabled it for a moment and "Run to completion" started to work as it should. I thought that the block's thread doesn't end because I've used timer inside of it. I've removed almost everything from this python message only block almost everything and what was left was only this: ------------------------------------------------------------------------------------- class clock_offset_control(gr.basic_block): def __init__(self, fc): gr.basic_block.__init__(self, name="gsm_clock_offset_control", in_sig=[], out_sig=[]) self.message_port_register_in(pmt.intern("measurements")) ------------------------------------------------------------------------------------- ... but still - if any message enters the "measurements" input, the block's thread doesn't end. Conclusions: thanks to you guys (Tom Rondeau and funkylab) I've finally found the source of the problem in my flowgraph. I still don't know why is it that my python message only block doesn't end as it should. Even if I won't find the answer for that, I can work around the problem by implementing the block in C++ (I have many C++ message only blocks that don't cause problems with "Run to completion"). Best Regards, Piotr Krysik _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio