-
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
ObservableSource.asFlow()
blocks the singleThreadContext/Dispatchers.Main on android, if the default buffer is exceeded
#3282
Comments
ObservableSource.asFlow()
blocks the singleThreadContext/Dispatchers.Main on android, if default buffer is exceededObservableSource.asFlow()
blocks the singleThreadContext/Dispatchers.Main on android, if the default buffer is exceeded
tl;dr: try
Most dispatchers, when asked to resume a coroutine, will not execute it immediately, but will schedule it. This is what happens here: no one is collecting anything, because the only thread in use is busy creating new elements and notifying the dispatcher that someone should process them. Some dispatchers, like On a separate note, it is incorrect to create |
Isn't this a common case of missing backpressure? RxJava commonly throws In this case it turns out that backpressure results in deadlock which is not common neither in RxJava nor in Flow hence unexpected for user. Maybe we can throw |
Oh, I see an issue, thank you. But this is completely unexpected for It would be much more informative to have an exception like the default Flowable behaviour, or another way to prevent this situations. Even the word about this in method documentation will enhance this issue investigation. |
@vganin this suggestion has some pros and cons.
@Motoaleks not sure what a good place for mentioning this issue would be, since this knowledge is just about |
I found an issue, that the next block of code suddenly blocks Dispatcher. It happens only on scopes with single thread attached (like created with
newSingleThreadContext("SingleThread#1")
orDispatchers.Main
on android). I understand, that the default buffer is 64 items and it should suspend sending and resume collecting if no back-pressure operator is applied. But why is this does not happen in that case?Seems that
runBlocking
under the hood ofasFlow
operator does not resumecollect
. Is there any way to preserve the context and handle this situation?case 1: JVM, with
newSingleThreadContext
code:
result:
deps:
case2: Android, with
Dispatchers.Main
code:
deps:
result is the same.
The text was updated successfully, but these errors were encountered: