Watching for registration with python

[Dan Williams]

On Fri, 2017-09-01 at 17:59 +0100, Colin Helliwell wrote:
> > On 01 September 2017 at 17:17 Dan Williams <dcbw at redhat.com> wrote:
> > 
> > On Fri, 2017-09-01 at 10:51 -0500, Dan Williams wrote:
> > 
> > > On Fri, 2017-09-01 at 14:26 +0100, colin.helliwell at ln-systems.com
> > > wrote:
> > > 
> > > > I've been having a look at the modem-watcher-python example,
> > > > and
> > > > would like
> > > > to do something similar - namely wait until the modem has
> > > > registered
> > > > on the
> > > > network and then grab the MCC/MNC.
> > > > Is there some sort of event I can hook for this (similar to
> > > > what
> > > > the
> > > > example
> > > > does with ' object-added'), or do I just need to poll?
> > > > Thanks
> > > 
> > > ModemWatcher.py has the modem watching stuff already. What you
> > > want
> > > to
> > > do is modify the on_object_added() method to:
> > > 
> > > 1) check modem.get_state() >= ModemManager.ModemState.REGISTERED
> > > 2) if yes, then grab the MCC/MNC with something like:
> > > 
> > > mccmnc = obj.get_modem_3gpp().get_operator_code()
> > > 
> > > 3) if no, then connect to the 'state' property notifier:
> > > 
> > > modem.connect('notify::state', self.modem_state_changed, obj)
> > > 
> > > and then have a separate function that handles that change:
> > > 
> > > def modem_state_changed(self, modem, prop, obj):
> > >  if modem.get_state() >= ModemManager.ModemState.REGISTERED:
> > >  mccmnc = obj.get_modem_3gpp().get_operator_code()
> > > 
> 
> ...
> > 
> 
> Thanks for the pointers, Dan. But isn't there a risk of race hazard
> (the state change) in between #1 and #3?
> In which case I was thinking (bearing in mind it's dinner time on a
> Friday...):

No, there's no race condition in this case (single-threaded) because
all the D-Bus signals are processed sequentially.  As long as you don't
let the mainloop run between 1 and 3, you will always see the correct
state.

> Connect to the 'state' property notifier *straight away* in the
> on_object_added() method; *then* also check modem.get_state() in
> there too.  [Provided I'm ok with the resultant code being
> potentially called twice]

Not necessary, for the same reason as above.  Since this is single
threaded, and since most of the GLib notify signals are only emitted as
a result of D-Bus signals which only get processed when the code in
question returns, there's no chance of a race here.

Basically, no changes to objects will happen while program control is
running your code.  And as long as you are setting any properties or
calling methods that would change things, you'll never see changes as a
result of things you're doing either.

But what you suggest would have no ill effects either.  Just that the
notify handler simply won't ever run since it would only get triggered
after this code returns to the mainloop, and then only if there is a
waiting D-Bus signal indicating a state change.

Dan