Parallel enables occurring (when SIM PIN enabled)

[Colin Helliwell]

> On 19 July 2017 at 07:42 Colin Helliwell <colin.helliwell at ln-systems.com> wrote:
> 
> > On 26 April 2017 at 17:48 Aleksander Morgado <aleksander at aleksander.es> wrote:
> > 
> > On Wed, Apr 26, 2017 at 6:23 PM, Dan Williams <dcbw at redhat.com> wrote:
> > 
> > > Patch was more for confirmation/debugging than intended for commit. We
> > > can plug this particular hole with patches like that, but probably want
> > > to figure out a more general strategy. That said, I think this the
> > > most likely case we'd encounter.
> > 
> > Also probably the easiest case to handle; queuing multiple Enable()
> > requests so that only the first request does the logic and the
> > remaining ones just wait for the first one to finish, is something we
> > can definitely do. This could also apply to the disable phase, or the
> > simple.disconnect, or the bearer.connect/bearer.disconnect phases.
> > 
> > Whenever there are specific settings requested for a given action,
> > though, (e.g. simple.connect) we should force to have a single
> > operation running always, and error out right away without waiting for
> > any final state (unless we also want to compare the settings and queue
> > the new request if the settings are the same one as the original one).
> 

> I'm needing to revisit this patch I've been using for this issue, in light of 'recent' changes to the 'EnablingContext' structure [is 'state' -> 'previous_state' *just* a simple renaming of the member?].

Ignore that bit - got confused about what I was looking at!


> But I wondered whether anything had been re-structured elsewhere which ought to address the problem anyway?
>