You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
FWIW I also forked async-task, though I actually removed all cross-thread synchronization (atomics) and related Send bounds. https://github.com/kabergstrom/async-task/
Just did it to see how fast one could make an executor that doesn't support cross-thread synchronization in the Task object, instead using a lockless ring buffer per executor to receive tasks. These single-threaded executors can be composed into groups, where task spawning can then be spread over the executors with user-provided load balancing algorithms (round robin provided). It's 2-10x faster on my machine in the microbenches people were arguing about recently. https://github.com/kabergstrom/lonely
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 aspawn()
method that are notSend
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.The text was updated successfully, but these errors were encountered: