-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Implement dispatching generic runnables to script event loops #3735
Comments
You mean to replace the current |
I'm pretty sure we'll need to retain at least some of the messages in there, but I would also be happy to be proved wrong. I was imaging RunnableMsg being another variant of ScriptMsg. |
Ok, I'll start to implement this approach with the XHR events you mentioned, then I'll ping you to check if I'm on the right track. |
what I did so far: https://github.com/thiagopnts/servo/blob/b014a7417cc9e8abf06528653cafa89ab2fbbd9b/components/script/dom/xmlhttprequest.rs#L83-L95 The main problem is processing the progress on the handler, I end up getting a:
Any thoughts on how to workaround this? I would also appreciate any resources on how to deal with boxed traits on channels. |
I would try making the |
This makes the object not safe:
|
:< Maybe &mut self? If not, then just clone the needed values for now. |
rust-lang/rust#19878 (comment) might be related (and/or suggest alternatives). |
This refs #3735. As discussed in the issue, I did it cloning when I couldn't dereference an attribute. The trait method should be on `&self` for object-safety reasons.
This refs #3735. As discussed in the issue, I did it cloning when I couldn't dereference an attribute. The trait method should be on `&self` for object-safety reasons.
For events that are dispatched to the script event loop from the script crate it would be cleaner to avoid adding implementation knowledge to script_task.rs - events like the XHR ones belong entirely to the XHR code. If we had runnables with closures, the script task could just invoke the closure without having to know anything about its contents. Something like
RunnableMsg(Box<Runnable>)
where Runnable is a trait with a method to invoke the closure would make a lot of sense; any state the closure required could be stored in whatever type is implementing the Runnable trait for that particular event.The text was updated successfully, but these errors were encountered: