Hi Tim - My vote is to let the scheduler decide. * In GNU Radio's "thread per block" scheduler, I think either will work correctly but I tend to believe returning 0 is preferred such that the scheduler can determine what to do next.
* In the older GNU Radio "single threaded scheduler" you'd want to have "work" return 0 and let the scheduler figure out how to handle it -- so as to allow other block's "work" to make progress during the waiting; if any "work" blocks in sleep or IO, all processing stops until the block is lifted. * Some alternative scheduler, maybe Josh's GRAS, could separate threads and blocks by using a cluster of threads and a smart queue to handle block execution in a combined FIFO / priority manner. In this case, the block should return 0 and let the scheduler decide, such that the "work processing" thread can be used for some other block's "work". When I look at these 3 primary ways of handling the "work", 2 of 3 should return 0 and not sleep or otherwise block, and the 3rd one can go either way. The basic idea is to keep "work" happening somewhere in the waveform/graph, by disallowing sleep or blocking IO. Hence, my vote to let the scheduler decide. I hope this helps; someone please correct me if I'm wrong somewhere or if there are other interesting ways to look at this issue. - MLD On May 6, 2013, at 6:09 PM, "Monahan-Mitchell, Tim" <[email protected]> wrote: > Looking at some source block examples (audio jack, comedi, file source, > etc.), sometimes I see a sleep() called inside the work function when there > is no data to read, sometimes not (noutputitems = 0). > > For a real file, not sleeping and returning noutputitems = 0 makes perfect > sense. > > For a stream device, using fread(), what are the pros/cons of the work loop > sleeping if fread is empty, or letting the scheduler decide? > > If I can influence the implementation of the device driver, similar question > on pros/cons if the driver sleeps (or schedules) instead if there is no data > yet, or just returns an empty read? > > (ignore endless looping for these questions, that could be detected) > > I will be using GR v3.7 when available. _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
