-
Notifications
You must be signed in to change notification settings - Fork 138
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
AsyncChannel naming is provisional and needs review #47
Comments
From a quick skim of the implementation and tests it seems Channel might be a good name for it hm hm 👍 |
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 |
Kotlin Coroutines names this [1] sender suspends on full; receiver suspends on empty. |
Is there an official definition to what a If the link @phausler has provided is considered an "official" definition, then I'm not sure we should keep the
On the other hand, if the accepted definition of |
I think |
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 moved the discussion above to its own issue. |
I would just model it Why reinvent the wheel? On a different note, |
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. |
@phausler I think we can close this issue now? |
Yea, the name feels pretty solid and has been reviewed. |
The naming of
AsyncChannel
was introduced as a placeholder name. It deserves more consideration to existing paradigms, the current name is inspired fromChannel
. This type needs a guide and some research/discussion on what a good name for this type should be.The text was updated successfully, but these errors were encountered: