AsyncChannel fixes potential crashes when no more awaiting

[twittemb]

This PR fixes potential crashes where the state is "awaiting" while there are no more awaiting clients.
The state is now set to .idle to reflect the reality.

This PR is linked to the issue #142.

The fix prevents the removeFirst() to be executed by preemptively setting the state to a correct value. It think the removeFirst() statements should be used in a more secure fashion though. It could be the subject of another PR.

It is hard to produce unit tests that ensure the crashes are fixed since we must set the AsyncChannel in an awaiting state. Ideas are welcome !

[phausler]

is there a stochastic test that we could add? e.g. something that if we run it 100/1000x times etc that it is likely to crash?

[phausler]

These changes look correct to me, perhaps we can also use the validation diagrams to build something to isolate this deterministically.

[twittemb]

Regarding the stochastic test, it seems hard because the last instruction of the test would be to send an element in the Channel to ensure it does not crash ... but if there is no crash then this last instruction will be awaited for ever, then the test never finishes.

func test_cancel_when_only_one_iterator_while_waiting() async throws {
  for _ in (0...100) {
    let channel = AsyncChannel<Int>()

    let task = Task {
      for await _ in channel {}
    }

    task.cancel()

   await channel.send(1) // -> never resume
  }
}

About the validation diagram, I'm not super aware of how it works but I can't see a way to interact with a Channel in the DSL. What do you have in mind ?

One way would be to test the internal state machine of the AsyncChannel but we would need a spy callback in the next() function to be able to trigger the task's cancellation in the unit test using an expectation. Doing so we only test the internal state machine though, we don't test the behaviour of the Channel as a whole.

[twittemb]

@phausler do you have other ideas ? I've tried to give it another thought today and I cannot figure out a way to test that it does not crash without having spy callbacks and internal state exposed :-(

[phausler]

sadly I have not had a lot of time to ruminate on an alternative to test this. To me it seems right, so I am going to go ahead and merge it with an issue to test it later.