Thanks for the responses. > That should be a clue. The throttle block absolutely works right after > a file source. It always has in the thousands of cases I've tried and > seen. <snip>
I'm still having this problem, even after creating the simplest flow graph possible: File source -> Throttle (val = 1) -> Terminal Sink. Terminal sink has the following code: const unsigned char *inputByte = (const unsigned char *)input_items[0]; std::cerr << (unsigned char)inputByte[0]; consume_each(1); return 1; I understand this is not ideal and could be looped for available items, but this is the simplest I could break the terminal sink down to. I assume there's something here I'm doing incorrectly, and that's why it is not working properly? My original flow graph does not use terminal sink, so it'd have to be a common problem to the other blocks due to a consistent programming error on my part (embarrassing, but it'd explain a lot). > I've been over the thread-per-block scheduler code a lot in the past > few years. What you are suggesting here is, frankly impossible. <snip> Totally understand and agree. I'll admit it was a bit careless to assume and speculate so much, but I'm simply flummoxed as to why sequential data would work while random data does not. I've never heard of any bug or feature (other than branch prediction) that would care whether the data was random or not. The fact that the file size contributes is confusing as well. I've done much testing on the individual blocks and everything seems to check out. > I suspect the change in behavior observed by the original poster is > caused by a race condition that manifests itself differently depending > on the relative speed of different flowgraph threads, to which branch > prediction failure rate would contribute. This was certainly my first thought of what could be happening, especially due to the server communication that's used and the threading model it uses. But after removing the server references from the flowgraph, the issue still occurs. The encode, decode, and BER block do not share any common variables and certainly no variables that persist outside of the work function. Is it possible a race condition is still occurring, even with nothing shared among blocks? _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
