async-rs / async-task Goto Github PK
View Code? Open in Web Editor NEWTask abstraction for building executors
License: Apache License 2.0
Task abstraction for building executors
License: Apache License 2.0
Currently waking the waker by value hands over the ownership of the task to the
schedule without retaining any refcount on its own. Once the scheduling
function hands over the ownership of task further there is no guarantee that
memory that holds scheduling function will remain valid.
For example (drop(task)
is used to avoid irrelevant complexity):
fn main() {
let s = "1234".to_owned();
let (task, _) = async_task::spawn(
async {},
move |task| {
println!("{:?}", s);
drop(task);
println!("{:?}", s);
},
(),
);
task.schedule();
}
Hello
When browsing code around, I've came to wonder about one thing. What would go wrong, if I created a trivial „recursive“ executor by running the task directly inside the schedule closure? Eg:
let (task, handle) = async_task::spawn(future, Task::run, ());
task.run();
So far, this has crossed my mind:
Or, are there any other problems or restrictions what the schedule closure can do?
There's a warning in the docs.
The Task
struct should have:
fn into_raw(self) -> *const T;
unsafe fn from_raw(raw: *const T) -> Self;
Both Task
and JoinHandle
should also have:
fn waker(&self) -> Waker;
Hi. I'm in the process of writing safe rust bindings for writing Weechat
plugins. Since the Weechat plugin API is inherently asynchronous albeit callback based I had the idea that it would be nice to be able to run rust futures inside of Weechat.
I used async-task to implement an executor that runs on the Weechat event loop rather easily, thanks for the awesome project.
Now to my problem, I have a bunch of Weechat objects that should only be used on the Weechat thread. Since Weechat is in no way thread safe all interaction with Weechat (e.g. printing messages in Weechat) needs to happen inside the Weechat thread.
Since our executor does run on the Weechat thread, futures that run on it should be able to use Weechat objects, but as Weechat isn't thread safe none of them should be marked as Send
.
What I would need to achieve this with async-task is a Task
struct and a
spawn()
method that are not Send
bound. I saw this issue on the async-std tracker, and it seems that I'm not the only one with such a requirement.
I would assume that any C project that runs on some event loop might want to implement an event-loop local executor as well, provided that they are writing rust bindings.
For reference, my prototype executor implementation can be found
here. I'm using a forked version of async-task where I just removed the Send
bounds.
It looks like version 2.0 has been pushed to crates.io, but it doesn't seem like anything has changed in this async-task repo in a few months. Is this just local development taking place or a different primary repo?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.