swift-async-algorithms
swift-async-algorithms copied to clipboard
apple
AsyncChannel naming is provisional and needs review
The naming of AsyncChannel was introduced as a placeholder name. It deserves more consideration to existing paradigms, the current name is inspired from Channel. This type needs a guide and some research/discussion on what a good name for this type should be.
From a quick skim of the implementation and tests it seems Channel might be a good name for it hm hm 👍 Need to think if we need to qualify it with some prefix or not -- when does the send return?
So the send returns in this case as soon as someone receives the value in an iterator. So it has the "async on both sides" behavior to ensure back pressure is respected.
I think the name AsyncChannel is well chosen - it is short and describes exactly the semantics.
Kotlin Coroutines names this RendezvousChannel. Though the "rendezvous" prefix is most likely a result of them also offering buffering variants [1] under the same Channel umbrella.
[1] sender suspends on full; receiver suspends on empty.
Is there an official definition to what a Channel should be? especially regarding the synchronisation part between sender and receiver.
If the link @phausler has provided is considered an "official" definition, then I'm not sure we should keep the Async prefix.
Channel alone would simply mean that we have implemented the official Channel paradigm with async/await as an implementation detail. Moreover AsyncChannel could be misleading by thinking Async means that sending a value is not bound to its consumption.
On the other hand, if the accepted definition of Channel does not imply the synchronisation between sender and receiver, then I guess Channel is a family of different implementations depending on the buffering policy (like Kotlin). If we want to go down that road then something like RendezVousChannel or similar could be interesting in comparison with a future BufferedChannel (which would be Channel + AsyncBufferSequence)
I think Channel and BufferedChannel works pretty well. I'm not sure the Rendezvous prefix buys us much. Also, since we're talking about BufferedChannel is there any work being done on that front? If not, I'm happy to contribute with an implementation/proposal.
Actually, this is (probably?) not possible to implement now, but it would be awesome if we could add deadlines to Channels like we did on Venice (backed by libdill). Like the test excerpt below:
func testDoubleSendTimeout() throws {
let channel = try Channel<Int>()
let coroutine1 = try Coroutine {
XCTAssertThrowsError(
try channel.send(111, deadline: 50.milliseconds.fromNow()),
error: VeniceError.deadlineReached
)
}
let coroutine2 = try Coroutine {
XCTAssertThrowsError(
try channel.send(222, deadline: 50.milliseconds.fromNow()),
error: VeniceError.deadlineReached
)
}
try Coroutine.wakeUp(100.milliseconds.fromNow())
let coroutine3 = try Coroutine {
try channel.send(333, deadline: .never)
}
XCTAssertEqual(try channel.receive(deadline: .never), 333)
coroutine1.cancel()
coroutine2.cancel()
coroutine3.cancel()
}
If not possible right now, what would we need in place to make it happen?
I would just model it 1:1 like channels in Go, so as for the name AsyncChannel would be correct.
Why reinvent the wheel?
On a different note, close seems like a more reasonable name for the finish method.
IMO the current semantics fit very well with what we want to achieve with this type. The intention is to have a multi-producer multi-consumer root asynchronous sequence that allows lock-step programming between the involved parties. This is exactly what this type offers.
