Just curious. Are you trying to implement a discontinuous streaming model? Or are you looking for a way to control start time but still continuous?
> > case uhd::rx_metadata_t::ERROR_CODE_TIMEOUT: > //Assume that the user called stop() on the flow graph. > //However, a timeout can occur under error conditions. > if (_start_on_demand == true) > //Start is first called by the gr_block_executor > //We are still waiting for the mannual start command > return work(noutput_items, input_items, output_items); > > return WORK_DONE; > FWIW, the current source block actually has a change to loop forever in the work function until the thread interrupted. This is because source blocks in gnuradio cannot return from the work function without producing. Although, it would be very nice for blocks like uhd source, udp source, and probably a few others that block on input IO to be able to return from work without producing. > > Unfortunately, although the new code passes the build, the behavior is > still strange, for below python code: > tb.start() # start flow graph > time.sleep(10) # wait 10 seconds to start the streaming > tb.source.u.start() > > Now the streaming is not started when tb.start() is called in the > beginning. But when 10 seconds sleep ends, the flow graph crashes by > reporting: "***glibc detected *** python: corrupted double-linked list: > 0x00007fcb640011c0", apparently on calling the > usrp_source.start() manually. I seems some memory issue happens, but in > usrp_source.start(), it just tries send a command to USRP. > > I suppose the streaming start and stop should be used easily but not know > why such kind of problem happens. > Still debugging it, any comments are appreciated. > I guess its necessary to determine which line of c++ is actually causing the error. One thing you may check, since you are stopping the first start from happening, is the rx streamer still getting created? The rx streamer needs to be created before work is called. You may want to check if the streamer is created so 1) you can avoid re-allocation, 2) stop work from calling into null streamer -josh _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
