Parallel enables occurring (when SIM PIN enabled)

[Colin Helliwell]

> 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?].
But I wondered whether anything had been re-structured elsewhere which ought to address the problem anyway?