[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Change Variable value from an python block or module?
From: |
Marcus Müller |
Subject: |
Re: Change Variable value from an python block or module? |
Date: |
Thu, 26 Mar 2020 00:46:45 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 |
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
>