Hi Jake, yes, that's true: The block_executer practically goes through an endless loop between handling input samples with (general_)work and handling messages with the registered message handler. The whole point of that is that you can send a message that would (logically) change something in the operation of the block, and it will never interfere with the operation of work – thread-safety! (imagine, for example, you changed the number of taps of a FIR filter right in the middle of that filter's operation – that would definitely lead to some unexpected results).
Best regards, Marcus On 10/04/2016 08:09 AM, Gavin Jacobs wrote: > > I am writing a block which takes a PDU input and produces a stream > output. I used a source block template with zero stream inputs, one > message input, and one stream output. I have implemented a message > handler and I can see my messages are being received. I need to pass > data from the PDU message handler to work(). I looked at the code for > PDU_to_tagged_stream and it appears that they use a private member > (d_curr_len) to communicate from the message handler to work - which > implies that the message handler and work are on the same thread. Is > this correct? i.e. can I use a plain FIFO queue from message handler > to work, or do I need a thread safe queue? > > > Thanks, > > Jake > > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
