On Wed, Sep 12, 2012 at 12:21 PM, Josh Blum <j...@ettus.com> wrote: > 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? > I think I want a way to control start time but still continuous. But I may know not so much about discontinuous streaming. What is the difference between the discontinuous streaming and the finite acquisition?
> > > > > 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 > Thanks for this indication, I will check if the incorrect object operation. > > -josh > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
