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