Re: [Discuss-gnuradio] Recent development activity, upcoming plans

[Josh Blum]

> 
> As for the unit testing, frankly, I don't care what tool is used so
> long as the behavior is the same as we have now. One thing that's
> important is that the QA results are stored in the XML files that
> Jenkins reads. I'm pretty sure Jenkins can handle Boost output files,
> too, but we'd want to make sure that was working cleanly if we made
> the move. What I don't want is to have two such systems running (we
> already have a Python and C++ unit test, which some find confusing
> already). So an switch would have to be made all at once. I personally
> don't see that it's such a big deal to go through that effort to make
> the change.
> 

Looks like Boost unit test can output XML FWIW. Dont know if thats a
format jenkins can parse:
http://www.alittlemadness.com/2009/04/07/boosttest-xml-reports-for-continuous-integration/

> Johnathan and I have discussed this, but I don't think we've come up
> with a plan. The idea is that we fix the issue of being able to
> manipulate pmt_vectors (and any other containers) after their creation
> such that all PMTs are now read-only. The PMT vectors are a good idea
> in that you want to be able to have a vector of items, but the
> implementation has allowed them to be changed, which produces thread
> safety issues.
> 

In the plan outlined in that ticket, gr_tag_t would be filled with
pmt_const_t and not pmt_t. This would prevent the downstream dudes from
violating the immutability contract with the upstream. The
implementation of creating and filling a PMT would not have to change.

> One request. Could you write either some documentation for how to use
> the message passing system or, probably better, a simple example that
> shows connecting blocks together and passing messages between them?
> That would help clarify their use. I'm not saying that this is a
> requirement before the merge, but it would be nice to see how it's
> used.
> 

Absolutely.

Here is a QA test:
https://github.com/guruofquality/grextras/blob/master/python/qa_msg_passing.py

And usage is fully documented on the blocks coding guide for c++/python:
http://gnuradio.org/redmine/projects/gnuradio/wiki/BlocksCodingGuide

> that doesn't require this. But again, I'm not sure where PMT creation
> is the bottleneck anywhere, and Boost intrusive pointers work really
> fast already.
> 

Boost intrusive pointers are great. But they are actually just
stack-allocated objects. Its the pointer you fill them with, which is
the allocation in question.

So, In small quantities, when latency isnt a concern, of course its not
a big deal. However, for large quantities, I learned this the hard way
with UHD and oprofile. If you have a malloc on every packet, the
overhead is on the same order of magnitude as converting a packet worth
of samples. So, it can be serious overhead, and its a good thing to give
users a way to avoid allocating heavily in the work function (should
they be using PMTs that heavily).

> I hope this clears up why the PMT read/write issue is a non-starter.
> I'd rather see a bit of slowdown then segfaults :)
> 

I'm not sure what segfaults you are referring to. But the thread safety
issue is already a problem. Technically, tags/PMTs are one giant race
condition if your downstream blocks do not follow the implicit contract.
We should fix this.

-Josh