This fixes the bug where in-flight async ops that were triggered
by DevReattacher (such as livoxGen1_attachDeviceReq) that have
unconditional delays in them would fire late, after the state
var they rely upon had already been de-initialized.
We use an async bridge to ensure that those ops get executed in
the background and then resume execution after the delay.
We now acquire the DevMgr qutex when doing the newDASpecInd async
op. The qutex is held across an async sequence with potentially
a real hardware blocking bottleneck.
Since we have no choice but to access the sh_ptr<SenseApiLib> for
a lib before we can get its Qutex, we use this flag to ensure that
we can know whether the SenseApiLib data structure and its Qutex
are still valid when we enter -- i.e, we ensure that the SenseApiLib
object wasn't destroyed under our feet.
This function is the backbone for the DeviceReattacher daemon. It
assembles a list of all DA specs which are known to Mrntt, but which
haven't been successfully attached as yet, and attempts to attach
them.
We no longer try to detach from the collection of specs. We
detach from the collection of attachedDeviceRoles. This means
our cleanup sequence no longer tries to clean up things that were
never set up to begin with.
This method wraps around attachAllUnattachedDevicesFromReq and supplies
it with a sh_ptr<> collection of all DASpecs parsed by the DAP parser
from the cmdline.
The initialization sequence now correctly initializes all DAP specs
given on the cmdline again.
This method now accepts a sh_ptr<vector<DeviceAttachmentSpec>> to
tell it specifically which specs to attempt to attach.
This enables us to implement different frontends that supply it
with collections of devices from different sources (GUI, cmdline,
previously failed-to-attach/hot-removed devices, etc).
SMO temporarily initializes none of the devices from the cmdline
during this commit as we transition to implementing the cmdline
collection frontend.
We've renamed these now to better reflect what they do.
* attachAllSenseDevicesFromSpecsReq=>attachAllUnattachedDevicesFromReq
* detachAllSenseDevicesReq=>detachAllAttachedDeviceRoles
This is also the first step in changing
attachAllUnattachedDevicesFrom to accept a sh_ptr<> to a collection
of DeviceAttachmentSpecs. This will enable us to unify the underlying
spec attachment logic and just create several front-ends for attaching
specs from multiple sources.
This performs a more complete device initialization and attachment
sequence. We'll do the corresponding teardown in the shutdown
sequence later.
We might probably do it as deviceRoleGoneAwayInd()
We've decided to add a separate notion of a DeviceRole to track attached
device roles now. We no longer use the collection of deviceSpecs to
track which roles have been attached. Rather, this list will simply
collate all known deviceAttachment specs which are expected to be
maintained in an attached state.
SMO can periodically scan through these and cross-reference this
collection with the collection of attachedDeviceRoles. Then it can
re-try to attach those which aren't currently attached at any given
moment. This will give resilience against device attachment failures
or device resets/malfunctions, at runtime.
This is logically cleaner and it begins preparing our next set
of restructuring changes. To wit: we're revamping the device
manager to distinguish between devices and their roles.
Async: Use new [Non]PostedAsyncCont and callOriginalCb
This new hierarchy of classes gives us a central mechanism for
managing both reply-posting and lockSpec unlocking.
* callOriginalCb: Now uses a modern C++ variadic template design
enabling it to handle both direct calling and std::bind()
re-binding of an arbitrary number of arguments from the caller.
This enables us to mostly eliminate the repeated, bespoke
definitions of callOriginalCb littered throughout the codebase.
We've also propagated these changes throughout the codebase in
this patch.
Gave me some ideas about how things should be structured. Apparently
merely using region-data-locked threads doesn't eliminate the need
for synchronization/locking. It just means your synchronization is much
lighter, in the form of localized variables.
It seems we'll need to maintain boolean trackers for certain
operations that shouldn't be performed concomitantly, and deny
the caller access to those operations in order to preserve
data sanity.
I guess we still ended up using locking after all. Tbh, I'm not even
sure this will make things end up being lighter: we may have to bounce
requests off, or perhaps re-enqueue them into the queue?
So maybe instead of bouncing requests off, we could re-add them to the
rear of the queue when they conflict with an ongoing request.
hayodea
latentprion