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 <steffenk...@outlook.dk > <mailto:steffenk...@outlook.dk>> 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:* steffenk...@outlook.dk <mailto:steffenk...@outlook.dk>; > discuss-gnuradio@gnu.org <mailto:discuss-gnuradio@gnu.org> > *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 >
