Release the plan manager lock as soon as the new plan is created and plan manager plan pointer updated.
In the past all the plan consumer handlers were run while the plan lock was held. This is not necessary, since a new plan is always created following a plan change, and the new plan is never mutated by the plan manager or any consumers.
The following considerations were taken into account:
Pebble API requests involving plan changes (i.e. AppendLayer, CombineLayer and SetServiceArgs) are synchronous and only complete (return) once all the PlanChanged callback handlers returned. This means that from a single API consumer point of view, once a change returns, the next API call made will be guaranteed to see Pebble in the updated state (single threaded consumer).
I've not considered a change in the design to make plan changes propagate asynchronously, as this would have changed the behaviour described above.
The plan pointer sent to the PlanChanged consumers, following the release of the plan lock (the new design), must be a copy of the plan pointer already obtained before plan lock was released (otherwise we risk reading the plan pointer value during another change from the API).
The following changes are introduced:
Make the PlanChanged callback handlers run without the plan manager lock.
Improve the unit test coverage to ensure plan change notifications take place as expected, with the correct plan content being sent.
@benhoyt I was thinking that before I move this PR to a final review state, whether you could take a quick peek to see if my approach feels acceptable for you ?
Release the plan manager lock as soon as the new plan is created and plan manager plan pointer updated.
In the past all the plan consumer handlers were run while the plan lock was held. This is not necessary, since a new plan is always created following a plan change, and the new plan is never mutated by the plan manager or any consumers.
The following considerations were taken into account:
I've not considered a change in the design to make plan changes propagate asynchronously, as this would have changed the behaviour described above.
The following changes are introduced:
Make the PlanChanged callback handlers run without the plan manager lock.
Improve the unit test coverage to ensure plan change notifications take place as expected, with the correct plan content being sent.