-
Notifications
You must be signed in to change notification settings - Fork 276
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
Improve get_scroll_node_state #3732
Comments
Here is a potential solution to make the operation non-blocking: Could webrender/webrender_api/src/api.rs Line 1003 in 1e5bf93
Take in a optional sender as argument(ipc-sender?), to be provided by the user of the API, on which various messages could be sent to the user of the API? That way, something like So it would also fix the issue of having to create an ipc-channel on each call, since the messaging would go over a previously established communication channel. if no sender was provided in |
It doesn't look like Gecko uses |
webrender/webrender_api/src/api.rs
Line 1345 in 1e044fe
The above call is blocking, and although I'm not familiar with the overall communication patterns of the components involved, I can imagine it could beneficial to not block on the reply, instead finding a way to get it as part of the general event-loop where the code is running.
The additional problem is that the blocking reply is received by creating an ipc-channel, and sending the sender half on an ipc-channel, at each call, and that can eventually crash the environment where webrender is running, for example Servo.
A quick band-aid fix for half the problem would be re-using a channel, as opposed to creating a new one for each call(this only fixes half the problem because sending a clone of the sender still creates an fd for each clone when it is received in the other process).
See servo/servo#23905 (comment)
And the matching issue: servo/ipc-channel#240
The text was updated successfully, but these errors were encountered: