Re: [Discuss-gnuradio] GNURadio retrictions

[Marcus Müller]

Hi Mostafa

On 11/25/2014 07:37 AM, Mostafa Alizadeh wrote:
>> No, it doesn't. At least the GNU Radio scheduler won't interrupt a work
>> function
>>
> 
> I believe in what I see in GNURadio! It forsakes the work's routine
> somewhere in amidst of it!!
This would *really* surprise me. What does "forsake" mean here? Does the
computer then execute another work function, just to come back to the
current one later?

>>
> OK, these information doesn't solve the problem at least for me who don't
> know anything about boost.
Well, the point here is that it's not about knowing boost, it's about
understanding multithreading on current operating systems, which is
quite a bit more theoretical. However, you're describing problems that
neither Sylvain nor me can reproduce and I'm afraid you have some
misconception about how things in GR work together, and how a thread works.

> I swear that I wrote a clean code :), I see what I see.
The code you shared did two different things, though you claimed it
should do the same. Sylvain and me *both* pointed out that it *should
not* do the same and the code works as designed. I swear your code does
what it should by definition. You just wrote the wrong code if you want
something else :)
> 
> This is also so complicated, I forgot to add, that sometime calling the
> produce() function before add_item_tag() increments the nitems_written()
> and sometime doesn't!!!! why??
produce() will always instantly increase the value nitems_written()
returns, because that is the only job of produce().
block::nitems_written() just calls block_detail::nitems_written() which
returns its underlying buffer::nitems_written() which is defined in
buffer.h as
    uint64_t nitems_written() { return d_abs_write_offset; }
The delegate chain for produce is block::produce returning
block_detail::produce which calls buffer::update_write_pointer which is
defined in buffer.cc as
    d_abs_write_offset += nitems;
There's no ambiguity anywhere here, no if()s, not a single point where
we don't increase the return value of nitems_written() by the amount of
samples you produce(). I don't see how that "sometimes" could increase
and sometimes not. Pretty sure you're not really seeing GNU Radio misbehave.

Best regards,
Marcus