[AsyncThrowingChannel] make the fail terminal event non async

[twittemb]

This PR is the sister of #152 and is linked to that issue #155.

Long story short: terminal events (finish/fail) should not imply a back pressure management since no further elements can be sent.

When fail is called:

• all pending and awaiting operations should be immediately resumed (in order to avoid potential infinite suspensions)
• further calls to next() will throw the error
• further calls to send(_:) will immediately resume

[phausler]

it might be worthwhile to investigate how this interacts with #167

[twittemb]

Hi. I think they collide. This PR also addresses the issue where the failure is lost. I encountered the problem while testing the “non async” version of the fail event.

Our implementation of the “Termination” enum is very similar except i have decided to remove the “terminal” variable and to add a new “terminated” case to the Emission enum. As “finish” or “fail” are both terminal events, I think it makes sense to integrate this concept directly to the Emission state. This way we can benefit from the exclusive values of the enum and we can’t be in both “pending” and “terminated” state at the same time for instance.

What do you think ? @phausler

[phausler]

I think if we are removing the back pressure on terminal events then your approach might be better. The one gotcha that I did run across is that once you consume the failure it needs to transition back to just a normal finished state; e.g. the case of iterating past a failure.

[phausler]

Modulo the one issue with terminal transitions after it being emitted this looks great.

[twittemb]

Modulo the one issue with terminal transitions after it being emitted this looks great.

thanks for the review @phausler. I've pushed a new version.

[phausler]

looks solid to me!