discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] scheduler doubt


From: Josh Blum
Subject: Re: [Discuss-gnuradio] scheduler doubt
Date: Sat, 15 Jun 2013 18:08:15 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6


On 06/14/2013 10:21 PM, Yogesh Dahiya wrote:
> sorry for last post it accidentally got posted
> 
> so i have work function which has infinite loop
> while(1):
>     #some work
>     if condition
>         do some more work
> now when this block get turn every thing is stuck on this block, other
> blocks are not given time. Shouldn't it be that after some time it is put
> on hold other blocks are given   cpu time and after some time it get its
> turn back and start from where it left
> 

In general, never block in a work function. If there is no input
available to process, no output to product, just call return.

The only exception is a source block. A source block has no inputs.
Therefore, a source block work is called whenever output buffers are
available.

Users often create source blocks to provide data from a source that is
external to the scheduling environment, like a file, usb, a network
socket...

I recommend that source blocks should only keep the work context for a
limited amount of time (usually a blocking call with a small timeout).
This is because a block's context may have other valuable tasks to perform.

Relevant:
http://lists.gnu.org/archive/html/discuss-gnuradio/2013-05/msg00124.html

> 2. prob
> I want my block to be called  even when there is no input to ports
> (depending on some internal condition which is changing with time i want to
> do some work). So for that i have set
> 
> self.input_config(0).reserve_items = 0
> self.input_config(1).reserve_items = 0
> 
> (I have two input ports) but its not working
> 

Yup thats intentional. No input data is available, therefore, work will
never get called. -- not until input becomes available.

You mentioned an "internal condition". Perhaps when this condition
changes, you can pass a notification message to one of the input ports
of that block. Would that methodology for you?

It would be nice if this internal condition was monitored by another
block which could post a notification message. But also, I should also
mention, there is an API way to post stuff to an input port of a block
from an external entity. See the post_input tag,msg,buffer api calls.
https://github.com/guruofquality/gras/blob/master/include/gras/block.hpp

-josh



reply via email to

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