Comments (9)
Could you please provide a definition of being cancel-safe?
from kanal.
Could you please provide a definition of being cancel-safe?
It's like atomicity: action will be fully performed or not performed at all if I cancel the future. I'm relying on the official tokio's documentation https://docs.rs/tokio/latest/tokio/macro.select.html#cancellation-safety
from kanal.
recv is not cancel safe, safety here means there is a small possibility that received data gets dropped in the future drop if in the exact time that future is dropping another sender writes data(it is memory safe, drop safe), it is because there is no cancelation API for futures yet.
we can implement another cancel safe less performant method until then.
from kanal.
Cancelation-safety is the tokio-specific term, but I think this should be noted in the documentation. Tokio is the most popular runtime after all. Should I keep issue open until cancel-safe version is implemented? Will it be?
Thank you for the answer.
from kanal.
Let's keep it open, I'm thinking of short-term and long-term solutions.
It surely should be documented in the right place of the project as the tokio is the most common async runtime.
The main source of the problem is the definition of the Future trait in rust language, it should have something like poll_try_cancel()->Poll<CancelationResult<Self::Output>>
and CancelationResult could be:
enum CancelationResult<T>{
Unimplemented,
Done,
Failed(T),
}
from kanal.
Hi @fereidani, thanks for the amazing crate, may I ask about is there any plan to implement kanal's select
? IMO, select
is a common use case.
from kanal.
@al8n please open a separate issue, we can discuss it there.
from kanal.
recv is not cancel safe, safety here means there is a small possibility that received data gets dropped in the future drop if in the exact time that future is dropping another sender writes data(it is memory safe, drop safe), it is because there is no cancelation API for futures yet.
received data gets dropped in the future drop
@fereidani I think the semantics need to be clarified a bit here. What is "the future drop" in this context? Do you specifically mean: there is a small possibility that data gets dropped if data is sent over a channel at the exact time that the receiver is dropped?
Or perhaps you mean that data could be dropped specifically in the case that the sender is dropped before it has fully finished sending the data because the sending future is dropped?
Either way, thank you for the work on this crate. Really stoked about the benchmarks/performance possibilities here. I would love to adopt this crate for messaging in the data system I am building, which is otherwise entirely tokio channels. I just need to ensure that the data delivery guarantees are well-defined.
In the case of the system I am building, receiver channels will live for the duration of the program, with only a few cases where oneshot pools (my custom implementation) are used to amortize allocation costs.
As long as data is not going to be lost from within a normal use of tokio::select!{..}
over long-lived channels, then this seems quite alright.
from kanal.
Hey @thedodd, Just like other Rust polled futures, once you start polling, you need to continue until completion. Dropping midway can leave the future in an uncertain state. For instance, in async Rust when making an HTTP request, dropping the future after polling it once may leave you unaware of the request's result or status. To sum it up, ensure you use .await or poll the future correctly until the result is delivered. I'll close this issue to avoid further confusion, if rust adds a safe poll cancelation method which is unlikely, I will adjust the API to that.
from kanal.
Related Issues (20)
- Add Oneshot implementation HOT 17
- Async can't utilize `KanalPtr` as effective as Sync HOT 1
- Miri error when forgetting Box<T> HOT 2
- oneshot deadlock in 0.1.0-pre8 HOT 4
- Intrusive variants HOT 3
- Feature: implement recv_timeout for AsyncReceiver HOT 2
- Kanal is slower than crossbeam HOT 1
- Incorrect Send and Sync bounds HOT 2
- Oneshot: Data race detected HOT 4
- Unsound implementation of `as_sync` HOT 3
- Usage example
- Feature: Provide a select! macro HOT 6
- Slow usize send when using `MiMalloc` HOT 1
- mixing sync and async context HOT 2
- `Stream` that take ownership of the `Receiver` HOT 1
- OneshotSender is not Sync HOT 1
- API design for oneshot sender
- Oneshot: UB triggered when using Axum HOT 2
- Sink impl for AsyncSender?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from kanal.