Send unit status #403
Send unit status #403
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## feature_unification #403 +/- ##
=======================================================
+ Coverage 77.68% 78.04% +0.36%
=======================================================
Files 236 248 +12
Lines 23042 23681 +639
Branches 3436 3516 +80
=======================================================
+ Hits 17901 18483 +582
- Misses 5141 5198 +57 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
|
|
||
| const UnitStatus& WaitSendUnitStatus() | ||
| { | ||
| std::unique_lock lock(mMutex); |
There was a problem hiding this comment.
| std::unique_lock lock(mMutex); | |
| std::unique_lock lock{mMutex}; |
| */ | ||
| Error SendUnitStatus(const UnitStatus& unitStatus) override | ||
| { | ||
| mUnitStatus = unitStatus; |
There was a problem hiding this comment.
consider adding lock_guard at the begining
| { | ||
| LockGuard lock {mMutex}; | ||
|
|
||
| if (auto err = mNodeInfoProvider->SubscribeListener(*this); !err.IsNone()) { |
There was a problem hiding this comment.
not sure if the case is possible, but what if mImageStatusProvider->SubscribeListener(*this) fails,
and Start is called one more time, mNodeInfoProvider->SubscribeListener(*this); is likelly to return AlreadyExists error.
Should this case be handle somehow, by adding DefferRelease, or checkong errors for AlreadyExists enum
There was a problem hiding this comment.
In out case if Start fails, we close whole application and systemd restarts it. So, we should either handle this scenario in all the cases or leave it as is.
|
|
||
| LogUnitStatus(); | ||
|
|
||
| // Send unit status |
There was a problem hiding this comment.
Looks like a redundand comment
| // Send unit status |
| return; | ||
| } | ||
|
|
||
| itemIt = mUnitStatus.mUpdateItems->end() - 1; |
There was a problem hiding this comment.
This way looks less magic :)
| itemIt = mUnitStatus.mUpdateItems->end() - 1; | |
| itemIt = &mUnitStatus.mUpdateItems->Back(); |
| return; | ||
| } | ||
|
|
||
| itemIt = mUnitStatus.mInstances->end() - 1; |
| return; | ||
| } | ||
|
|
||
| instanceIt = itemIt->mInstances.end() - 1; |
| return AOS_ERROR_WRAP(err); | ||
| } | ||
|
|
||
| it = mUnitStatus.mInstances->end() - 1; |
| mUnitStatus.mUnitSubjects.Reset(); | ||
| }; | ||
|
|
||
| void UnitStatusHandler::StartTimer() |
There was a problem hiding this comment.
Does this implementation restart timer on each call like in Go it does, to wait some time for new updates before sending?
We need two times more update items in unit status to have already installed status and new item status. Signed-off-by: Oleksandr Grytsov <[email protected]>
Signed-off-by: Oleksandr Grytsov <[email protected]>
Signed-off-by: Oleksandr Grytsov <[email protected]>
Signed-off-by: Oleksandr Grytsov <[email protected]>
Signed-off-by: Oleksandr Grytsov <[email protected]>
al1img
force-pushed
the
update_manager
branch
from
ed6e1a0 to
5b18362
Compare
2 participants
No description provided.