discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Source block question: internal sleep loop or let


From: Michael Dickens
Subject: Re: [Discuss-gnuradio] Source block question: internal sleep loop or let GR scheduler handle empty read?
Date: Mon, 6 May 2013 21:47:27 -0400

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" <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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]