> 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?]. 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
