Sven Göthel

> Urk; not good. Surely we can have a getSocketPollUnlocked() and just assert that _lock is taken in there; or better just use _lock directly in that section - surely...

> In general adding a new lock is a nightmare. We want to reduce the number of locks, and simplify interactions. I also would only use synchronization when demanded by...

Little call-tree analysis Called with guarded _lock, safe - UnitBase::endTest () - caller UnitBase::exitTest Called outside by diff threads, needs sync for _socketPoll) - UnitKit::postFork - UnitBase::~UnitBase - UnitBase::socketPoll()

Best semantic coverage would have been to use C++20 `atomic _socketPoll`, but not possible due to tooling (see above). I.e. this would made clear that there are no mutex side-effects...

Force push provides a new proposal for clarification, i.e. no-side-effect usage of synchronized shared_ptr, please read updated description. If accepted, I would propose to move the new AtomicSharedPtr to online's...

One log/trace produced with my instrumented code earlier showing the data-race on _socketPoll. Compare my marks `JAU 02` and `JAU 10` showing Backtraces from different threads both originating from `UnitBase::socketPoll()`....

This change set created a linkage error (android), the ['usual' type_info, vtable thing](https://cpci.cbg.collabora.co.uk:8080/job/github_android_app_co-24.04/2725/console). Can't figure a missed 'virtual' or even pure virtual '=0' *virtual key* in the code, also reviewed...

Thank you @Ashod for the review. > I understand this is a draft, but it reads like a mix of random fixes and improvements (some of it is good and...

Thank you both for your review and kind words. I have split up single commits into 4 branches, i.e. this pull-request branch and - #9952 - #9953 - #9954 For...

> As said needs to be split up; lets try to get the less controversial pieces in and merged as separate pull requests - to slim this down =) Can...