-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected tag-handling with multi-threaded scheduler #347
Comments
This is basically the same issue as the one that is blocking the DataSet sink. Tags are unconditionally consumed not considering if they were applied at all. Unfortunately fixing it had some knock on effects to be taken care of. |
I've also come up with a case where using the single-threaded scheduler, a tag is output in the first item published by a block, but the tag is not present in the I can try to make a small example if this is not part of the same known problem. |
I confirm that this particular example is now working with the latest gnuradio4 main. |
I have a simple example that works as expected with a
gr::scheduler::Simple<gr::scheduler::ExecutionPolicy::singleThreaded>
scheduler, but fails with agr::scheduler::Simple<gr::scheduler::ExecutionPolicy::multiThreaded>
scheduler due to unexpected tag propagation.The flowgraph is Vector Source -> CRC Append -> Null Sink. The Vector source generates repeatedly 1500 bytes with a
{"packet_len", 1500}
tag in the first item of each repetition. The CRC Append block expects a stream of packets delimited with tags in this way at the input, and produces a stream of packets also delimited by tags by appending a CRC-32 to each packet (so the output packets are 1504 bytes long.When run with the single-threaded scheduler, the flowgraph runs forever and doesn't fail (the example should be built with
cmake -D CMAKE_CXX_FLAGS=-DTRACE
to enable prints in theprocessBulk()
function of each block). When run with the multi-threaded scheduler, CRC Append gives an error because it doesn't find the"packet_len"
tag at the expected location. The output looks like this:The problem is that the "packet-len" tag is present in a
processBulk()
call which hasinSpan.size() = 0
, but it is not present afterwards:This is unexpected for me, since I wouldn't expect tags to be present when
inSpan.size()
is zero. I would expect the tag and its "associated item" to travel together, and only have the tag present if theinSpan.size() > 0
and the associated item is the first one ininSpan
.The text was updated successfully, but these errors were encountered: