Thanks for answering. I got the point.
- Combine is pull-based (or request/demand-based).
- Therefore, messages cannot be pushed into downstream pipeline with no request.
- Request happens in the downstream context.
Therefore there's no way to "request" message until downstream context starts. Am I understanding correctly?
Now I understand why this behavior cannot be fixed and why
.buffer(...) makes pipeline to work as I expected. And it seems you guys don't like to change implementation for API design improvement. Then maybe further discussion about API design would be meaningless.
This is sad because just IMO, if it was push-based with checking available capacity of downstream, so upstream retained control, maybe this doesn't have to work in this way. Anyway, that could come with another downsides.
Though I think this could have been better, but I don't have proven designs or solutions, and I cannot make any more request to you guys. Thanks for your works.
Though this looks quite safe, but I cannot take this solution.
- I treat RunLoop/GCDQ as globally mutable collection of arbitrary opaque code, I don't like to run such "potentially anything is possible" blocks before sending message that has to be first.
- I don't want any stopping of UI thread even for 0.1 second.
- I am not sure how long I should run run-loop to "guarantee" processing of all queued messages in run-loop.
- In my experience, relying on this kind of solution increases potential of subtle bugs a lot on later stage of development. I am going to be away as much as possible from this kind of solutions.
Thanks for the suggestion anyway.
For now, I just use
.buffer(...).receive(on:) to make my pipeline to work as I desired. I think this would be enough for me. Taking potential message loss is painful, but it seems it's time to compromise.