Classes such as BehaviorSubject are at risk of deadlock, and there are issues with how locks are used.

[CloudlessMoon]

For example, BehaviorSubject, as shown in the code below:

The observer.on(.next(element)) operation is executed in the performLocked block. If the onNext block of the business logic contains serialQueue sync, there is a high risk of deadlock. For example, consider the following code:

observer.on(.next(element)) should execute after unlock. I think that the lock/unlock block should only contain internal logic, and business logic should not be included within the lock/unlock block.

It should be so, pseudocode:

Reproducible Demo: RxSwiftTest.zip

Running the demo can reproduce this problem. If it's not reproduced, you need to retries a few times; usually, it can be reproduced in 1-5 tries. In the demo, after a deadlock, ---rx end not all output. In Combine, the same code will always all output ---combine end.

[hiSandog]

I would make the reported environment part of the regression coverage for Classes such as BehaviorSubject are at risk of deadlock, and there are issues with how locks ar..., rather than leaving it as a manual reproduction. That is especially helpful if future dependency or toolchain updates touch BehaviorSubject.