Delete_head_blocking()

GNU Radio
1

Hi All,

I have been trying to understand delete_head_blocking() function from
gr_basic_block, but couldn’t understand much clearly. Can anybody shed
some
light on this. Also I want to understand pair(car-cdr as well), any info
would help.

Thanks a lot.

Shashank

2

Hi,

On 06/27/2013 11:18 PM, Shashank G. wrote:

I have been trying to understand delete_head_blocking() function from
gr_basic_block, but couldn’t understand much clearly. Can anybody shed
some light on this.

I think this function is useful if you have a block with a message input
and a stream output (i.e., the block has a work function). To avoid that
the scheduler has to call the work function all the time even if there
is no message to handle, you can block in the work with
delete_head_blocking() until you receive a message.

Also I want to understand pair(car-cdr as well), any
info would help.

car and cdr seam to be some old school functions from Lisp times.
They are used to access the first and respectively second element of a
pair. You might want to use them in conjunction with PDUs, as PDUs are
pairs of a dictionary with metadata (1st element) and a blob with the
actual payload (2nd element).

Best,
Bastian

3

Hi,

On 06/28/2013 08:57 AM, Martin B. (CEL) wrote:

Synopsis: Don’t block in work() => don’t use this call.
Perhaps it makes sense to register a message handler (think of it as a
work function for a specific message).

Even if the only input of the block is a message port?

Bastian

4

On Thu, Jun 27, 2013 at 11:18:51PM +0200, Shashank G. wrote:

Hi All,

I have been trying to understand delete_head_blocking() function from
gr_basic_block, but couldn’t understand much clearly. Can anybody shed some
light on this. Also I want to understand pair(car-cdr as well), any info would
help.

If you want to learn from my mistakes, check out the rev history on
header_payload_demux :slight_smile:

Synopsis: Don’t block in work() => don’t use this call.
Perhaps it makes sense to register a message handler (think of it as a
work function for a specific message).

MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

5

On Fri, Jun 28, 2013 at 10:48:09AM +0200, Bastian B. wrote:

Hi,

On 06/28/2013 08:57 AM, Martin B. (CEL) wrote:

Synopsis: Don’t block in work() => don’t use this call.
Perhaps it makes sense to register a message handler (think of it as a
work function for a specific message).

Even if the only input of the block is a message port?

In that case, there is no reason to block anyway. If you have two
message ports as input, blocking might even cause a deadlock.

MB

Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

6

On 06/28/2013 11:21 AM, Martin B. (CEL) wrote:

In that case, there is no reason to block anyway. If you have two
message ports as input, blocking might even cause a deadlock.

so it is the intended behavior that the work function is called all over
the time (and immediately returns)? I just checked for the pdu to tagged
stream block and its called ~500k times per second.

7

On Fri, Jun 28, 2013 at 6:48 AM, Bastian B.
<[email protected]

wrote:

so it is the intended behavior that the work function is called all over
the time (and immediately returns)? I just checked for the pdu to tagged
stream block and its called ~500k times per second.

This is a known issue specific to the design of streaming source blocks
that depend on async message input port(s) for their content. It will
be
addressed after the 3.7.0 release. Basically, we need to provide a
mechanism to allow a block to tell the scheduler to add reception of an
async port message as one of the conditions to be satisfied before
calling
work().

In general on this issue, the desired block design is to handle all
incoming async message port traffic using registered message handlers.
The
message handler(s) can then optionally generate futher outgoing async
messages on output message ports and/or set block internal state as
needed. Once the scheduler has dispatched all pending async messages to
the block’s message handlers, if the block has a work() function,
conditions will be evaluated whether to call it. If called, the work
function can then deal with streaming port I/O and any state updates
created by the prior message handler execution.

Since the GNU Radio scheduler is actually distributed among all the
blocks/threads, each block has its own scheduler that wakes up when
events
occur, evaluates whether to call block message handlers and work()
function, sends notifications to other blocks based on the return from
work(), and goes back to sleep waiting for another event to occur.
Blocking in either a message handler or in the work() function is very
strongly discouraged, as this prevents the scheduler for that block from
running and may result in deadlocks.

In some cases, usually in source blocks, making blocking system calls is
unavoidable, and we “get away” with doing so by using a timeout with a
small value and returning. This is suboptimal for CPU usage but does
allow
the scheduler machinery to run. (The pdu_to_tagged_stream block cannot
even
do this right now.)

Longer term, the plan is to add scheduler provided functions to call so
block work() functions can ask the scheduler to “call me again when this
happens” and the scheduler can handle the blocking/response in a way the
gets along with everything else.

TL;DR We’re working on it :slight_smile:

8

OK, I see. Thanks for that detailed explanation!

Bastian

On 06/28/2013 04:29 PM, Johnathan C. wrote:

be addressed after the 3.7.0 release. Basically, we need to provide a
conditions will be evaluated whether to call it. If called, the work
running and may result in deadlocks.
gets along with everything else.

TL;DR We’re working on it :slight_smile:

–
Johnathan C.
Corgan Labs - SDR Training and Development Services
http://corganlabs.com

–
Dipl.-Inform. Bastian B.
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

9

Longer term, the plan is to add scheduler provided functions to call so
block work() functions can ask the scheduler to “call me again when this
happens” and the scheduler can handle the blocking/response in a way the
gets along with everything else.

TL;DR We’re working on it :slight_smile:

This feature is already available in the advanced scheduler. Not happy
with your input, just mark the port fail, your work wont get called
again until the state of the port changes:

Cheers!
-josh