Re: Change Variable value from an python block or module?

[Marcus Müller]

Hi Nick,

great, now I have to write this email in a witch theme.

Don't you worry, we haven't had a public drowning and/or burning of
design idea dissidents since I think v3.7.6.3; we usually just rat them
out to their mothers.

Anyways, I fully agree with you, but only if we touch all our code. Let
me explain:

The fact that blocks have setters is ultimately very convenient.
However, and that happened multiple times, it's likely that a lot of
these were either conjured in the Single-Threaded-Scheduler times, or
simply without consideration for what a race condition is. And as you
guess, that means fun for the whole coven, when you – for example –
access the container for your items while vector_sink is putting more in
there.

Now, a lot of the setters are actually fine – they use a mutex to make
sure they're not changing any data structure general_work() is currently
operating on. Others only change a single scalar value – and on most
platforms, the likelihood of a 64 bit variable write not being atomic
are smaller than say, Walpurgis' Night and Easter being apart by exactly
a month (so, one in fifty times, give or take a few).

We just need to make sure *all* setters actually ensure atomicity or
mutexing, if we encourage increased usage of these.

Message passing inherently solves that problem by making sure that
messages are only processed when general_work isn't, and then only one
after the other.

So, I don't think you're one frog's eye short of an elixir:
We *should* have something that allows, with minimal-as-possible code,
to allow for asynchronous messages (not necessarily in the PMT sense,
but that's a different kettle of children) to be used to set stuff.

I envision, and I had, but never finished, then threw away, single-line
code that you can just call either in your block's constructor, that
templatedly generates a message handler wrapper around a given setter.

The templating stuff is actually not as cool as it sounds: it
essentially means you have to have done that at compile-time, bad deal.

Generally, `message_port_register_in` / `set_msg_handler` doesn't
discriminate as to whether the function supplied is a method of the
instance it belongs to, so you could always attach "external" message
handlers. All that's missing is a bit of usability sugar!

Cheers,
Marcus

On 25.03.20 16:41, Nick Foster wrote:
> You know, maybe this is opening up a can of worms, but you *can* do
> this. A lot of blocks don't accept messages; messages aren't exactly
> first-class (in the sense that every block accepts them) in Gnuradio.
> All blocks have getters/setters to change parameters, but only a
> comparative few have message slots, even though their functionality
> usually overlaps.
> 
> I'm currently doing this (callbacks) to interface Gpredict to a GRC
> flowgraph to provide Doppler correction. A Python block takes a callback
> to tb.set_<varname>() as a parameter, and sets the Doppler correction
> frequency as needed using the rotator block, which does not accept
> messages. It's easy, convenient, and didn't require modifying anything.
> The process has made me think a bit about messages in GR.
> 
> I'm sure anyone who's spent time looking at performance in GR is
> cringing right now, but a more generic way of doing this would be for
> GRC blocks to register slots (for message sinks) and signals (for
> message sources). Within GRC, message slots could be automatically
> generated for every callback defined in the .yml. It wouldn't require
> any changes to any blocks, which seems like a win to me, rather than
> changing every block in GR to add message inputs for all setters.
> 
> Nick, waiting for the chorus of "BURN THE WITCH"
> 
> On Wed, Mar 25, 2020 at 8:14 AM Steffen Kiel <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Hello Marcus,
>     alright, i will look into this whole "message" thing instead then.
> 
>      thanks for your quick reply.
> 
>     BR, 
>     Steffen
> 
> 
>     ------------------------------------------------------------------------
>     *Fra:* Müller, Marcus (CEL)
>     *Sendt:* Onsdag 25 Marts 2020 16:05
>     *Til:* address@hidden <mailto:address@hidden>;
>     address@hidden <mailto:address@hidden>
>     *Emne:* Re: Change Variable value from an python block or module?
> 
>     Yes, but no!
> 
>     So, GRC Variables are really a GRC concept, and you'd need to break
>     multiple layers of encapsulation from within a Python block just to
>     alter them. Really, that's possible with a simple callback function,
>     but please don't.
> 
>     Instead, the appropriate way of dealing with this would be giving the
>     signal source a message port, on which it accepts new values via
>     message.
> 
>     Then, from your Python or C++ block, just send a message.
> 
>     Best regards,
>     Marcus
> 
>     On Wed, 2020-03-25 at 14:57 +0000, Steffen Kiel wrote:
>     > Hello!
>     > 
>     > I have a signal source whose frequency input is referenced to a 
> variable.
>     > Is it possible to access this variables value and set it from a python 
> block or python module?
>     > 
>     > BR,
>     > Steffen
>