> > 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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
