Allow VirtualTimeScheduler to run on any thread #2610
Conversation
…ethods are all called on the same thread.
|
As far as I can tell, this is 100% backwards compatible and doesn't require any API change from users of the library. It may not solve every future use-case that Swift Testing might throw at it, but it solves the single most obvious one. I see no reason that this can't be accepted into the next minor release/update. |
| guard thread == nil || Thread.current == thread else { | ||
| rxFatalError("Executing on the wrong thread. Please ensure all work on the same thread.") | ||
| } | ||
| thread = Thread.current |
There was a problem hiding this comment.
Is it safe to read and write thread without any locking?
There was a problem hiding this comment.
Isn't that what we always do on the main thread? Read/write without locking? Maybe I don't understand the question...
There was a problem hiding this comment.
Indeed, it should be completely fine as long scheduler's methods are actually called on one thread, but what if there would be two close calls from different threads, it's not impossible that both will see thread == nil and proceed, for example.
There was a problem hiding this comment.
Right! Good point. I will update to account for that.
There was a problem hiding this comment.
@nikolaykasyanov What do you think about just assigning the thread in the init? Then we won't need a lock...
|
What's the hold up in getting this merged? Would love to start being able to migrate our RxSwift tests to Swift Testing @nikolaykasyanov @danielt1263 |
…as long as critical methods are all called on the same thread.
This is designed to fix issue #2609