[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Discuss-gnuradio] block::system_handler done message format
From: |
Jared Dulmage |
Subject: |
[Discuss-gnuradio] block::system_handler done message format |
Date: |
Thu, 2 Jul 2015 03:11:43 +0000 |
As I was investigating the message passing subsystem I noticed that my own
blocks had a "system" port that I did not manually register. Looking through
the code I found in block.cc the special message to put the block in a finished
state:
void
block::system_handler(pmt::pmt_t msg)
{
//std::cout << "system_handler " << msg << "\n";
pmt::pmt_t op = pmt::car(msg);
if(pmt::eqv(op, pmt::mp("done"))){
d_finished = pmt::to_long(pmt::cdr(msg));
global_block_registry.notify_blk(alias());
} else {
std::cout << "WARNING: bad message op on system port!\n";
pmt::print(msg);
}
}
Maybe I don't understand the reason for this, but it appears that this code
requires pmt::cdr(msg) to return a long int and then implicitly casts to a
bool. Wouldn't it be better for this to be a bool already such that a message
could be constructed like
pmt::cons(pmt::mp("done"), pmt::get_PMT_T())
or Python
pmt.cons(pmt.to_pmt("done"), pmt.PMT_T) ?
Perhaps it really doesn't matter. It just seems more natural, particularly if
one were to put a logical statement as the argument to pmt::cons.
Jared.
------------------------------------------------------
Jared Dulmage
Engineering Specialist
Digital Comm. and Implementation Dept.
Aerospace Corporation
310-336-3140
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Discuss-gnuradio] block::system_handler done message format,
Jared Dulmage <=