-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Mono.awaitSingleOrNull non-compliance with 2.7 #3363
Conversation
reactive/kotlinx-coroutines-reactor/test/MonoAwaitCancellationStressTest.kt
Show resolved
Hide resolved
Filed an issue to Reactor about this, as, after some research, it does look like a clear-cut case of non-compliance on their part: reactor/reactor-core#3117 However, currently, we're also non-compliant. I propose that we fix and merge it without testing, so that, when a Reactor version with the fix is available, users of our code obtain compliant behavior from us immediately. |
Just FYI. Having |
@OlegDokuka, the interpretation that 2.7 means that |
@dkhalanskyjb rule 3.5 is not about race conditions but rather about idempotency (if canceled once, the following cancelations should have no effect on the state) and non-blocking behavior (the caller thread MUST not be blocked waiting for other thread or stolen by CPU-intensive work). That means the
it makes no sense to have such behavior since
|
Could you clarify this? I'm not sure that it's not also about race conditions. In particular,
where thread-safety is defined as
in addition to idempotence seems to imply that it the subscriptions must be prepared for several calls to |
@dkhalanskyjb indeed, it sounds like about racing but the intent is different I guess we can clarify it in the spec. Also, I suggest paying more attention to the hint which aims to explain a dedicated rule in deeper detail and clarify its wording.
Not really, thread-safe in that context means
or, asynchronous - which means another concurrent thread is calling cancel while
The above can be easily derived and concluded from the term Besides, I will create a separate PR to clarify rules 3.5 as well as 2.7 so it is going to be easier to understand |
@qwwdfsad this PR is not really relevant, so my suggestion is to reject it. |
I think we'll keep this open as a reminder until the spec is changed. |
Hey @OlegDokuka, any progress on updating the spec? I don't see any new proposals in https://github.com/reactive-streams/reactive-streams-jvm/pulls — is that the place to look? |
Ok, I give up, this PR is certainly not useful anymore. |
No description provided.