> On 19 July 2017 at 07:42 Colin Helliwell <colin.helliw...@ln-systems.com> > wrote: > > > On 26 April 2017 at 17:48 Aleksander Morgado <aleksan...@aleksander.es> > > wrote: > > > > On Wed, Apr 26, 2017 at 6:23 PM, Dan Williams <d...@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? > _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
