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
Create an API to retrieve the HandlerId
of a Worker
from its WorkerBridge
#241
Comments
Pinging @futursolo for their feedback |
You should be able to do this with AnyMap. let mut workers = anymap::AnyMap::new();
let worker = CalculatorWorker::spawner().spawn("/calculator.js");
workers.insert(worker);
workers.get::<WorkerBridge<CalculatorWorker>>().expect("failed to get worker"); |
There should be a convenient way to retrieve it. I have seen in the markdown example that the #[derive(Debug)]
pub enum Msg<T> {
Respond { output: T, id: HandlerId },
} Why do this if there is no way to make it match with a worker bridge? If you find this modification pertinent, I would be happy to develop it as my first contribution to the project! |
This is internal message for the worker itself. The output type is
Reasons not to expose HandlerId on bridges:
I don't think it's a widely used practice to use ID-based APIs in Rust. https://doc.rust-lang.org/std/any/struct.TypeId.html Personally, I would not like to see I will leave the final decision to @hamza1311 . |
I agree with not exposing the Id directly. If there's a need to expose the id, it can/should be done through an opaque type. If we were to change how the id is stored, it shouldn't be a breaking change. I haven't had to use this crate myself so I can't comment on the need of it. I'd be happy to merge any PRs related to this. @futursolo, you can make the decision on if this should be added or not. |
Just for the sake of the example: When managing a bunch of workers, all are spawned to realize a specific task. That would be very convenient if I could respond I would rather trust you with design patterns, being very new in the rust community. @futursolo, feel free to close the issue |
I have created a proposal #251 to introduce functional workers that can run asynchronous tasks without them being identified by |
Summary
A user should be able to retrieve the HandlerId of a worker from its unique Bridge.
Motivation
Some Application potentially spawns many workers and needs to store a lot of Bridge within a HashMap; we could keep track of which Bridge is linked to which worker if that was implemented.
Detailed Explanation
We could develop an API to get the ID from the bridge.
Drawbacks, Rationale, and Alternatives
I propose this design cause I believe it has not been thought of. I might be wrong; there might be another solution to retrieve the id, which I have not found.
The function would return
usize
.I'm open to discussion if there are any drawbacks I am unaware of. For now, I don't think returning a
usize
could be an issue.Unresolved Questions
N/A
The text was updated successfully, but these errors were encountered: