Open gterzian opened 5 years ago
Here is a potential solution to make the operation non-blocking:
Could
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 get_scroll_node_state
could just send the request to get the scroll-states, without blocking on the reply, and the reply would be communicated via the "sender" provided at the create_api
call. It would then be the responseability of the API user to handle these messages and do what it needs to do with the scroll-states.
So get_scroll_node_state
would become a way to "ask for an update", which would later come-in via one or several messages, to be handled by whatever is the appropriate event-loop that the user of the API is running?
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 create_api
, you could fallback to blocking mode.
It doesn't look like Gecko uses get_scroll_node_state
anywhere, so we can shape it in the way Servo needs without worrying about breaking anything.
https://github.com/servo/webrender/blob/1e044fe1862373a055dbfb39930ead035e55b30f/webrender_api/src/api.rs#L1345
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 https://github.com/servo/servo/issues/23905#issuecomment-518785095
And the matching issue: https://github.com/servo/ipc-channel/issues/240