On Mon, May 6, 2013 at 9:47 PM, Michael Dickens <[email protected]> wrote: > 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
Yes, leave it to the scheduler. You don't want to be sleeping in a block, unless that's part of its normal function. You also don't want to have a blocking call inside of a work function, unless it can be interrupted. Tom > 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
