Hi! > This is the first odd thing, and I believe the cause of the problem. > Your source does not block until it receives something. > Generally speaking, returning 0 is a bad idea. > > In the case of sources, you should block until you get something, then > return whatever you got. The source receives data from time to time. If I return -1 if there is no new data, the scheduler marks my source as "done" and skips it forever. How should I block?
> What happens when any block declares that it is done, is that > everything is allowed to run until no further progress can be made. > In your case, the upstream block, the tcp_source, will run until it's > finally "output blocked" because of "back pressure" that results > because gr.head is done. Given that your source produces 0 output, > it'll never see any back pressure and thus will never end. Ok. I understand that there should be some back pressure. But in this case, back pressure is predictable. It is just a question of the buffer size. gr.head owns more buffer space than it will ever process. > Philosophically, we don't stop everything as soon as any block says > it's done, because other blocks may have side effects that we are > still interested in (e.g., logging results), or are still able to make > progress. How will a block make progress, especially a source, if his outputs are blocked? If all outputs of the source are blocked because they are done, I think it is a good indication that signal processing is completed. I do not really need this outside my testcase, since in a real application, it should not quit when the graph stops. > Outside of your test case, what are you really trying to do? Transferring status information in an evaluation system from a receiver to the transmitter. Thanks for your reply, Dominik _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
