Re: [Discuss-gnuradio] Source block question: internal sleep loop or let GR scheduler handle empty read?

[Tom Rondeau]

On Mon, May 6, 2013 at 9:47 PM, Michael Dickens <address@hidden> 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" <address@hidden> 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.