Allow using IPC to handle navigations #222
Conversation
…/verso into navigation-handler
|
I think before we start dealing with bi-direction communication API, there should be a dedicated IPC channel that could send from core crate to verso crate. Could you test if this could be done upon we start the IPC channel here? |
|
I thought about it before, but now I think I would like to go with the event listener approach that we only send an IPC sender to the core crate when we need info from it, instead of always listen to messages from the core crate |
| if let Some(ref sender) = *self.event_listeners.on_navigation_starting.lock().unwrap() { | ||
| let (result_sender, receiver) = | ||
| ipc::channel::<bool>().map_err(|e| ipc::IpcError::Io(e))?; | ||
| sender | ||
| .send((url.into_url(), result_sender)) | ||
| .map_err(|e| ipc::IpcError::Bincode(e))?; | ||
| let result = receiver.recv()?; | ||
| Ok(result) | ||
| } else { | ||
| Ok(true) | ||
| } |
There was a problem hiding this comment.
I still believe there needs to be a dedicated channel for communicating asynchronously. The lock and recv here are strong deadlock material.
There was a problem hiding this comment.
The lock and recv here are strong deadlock material.
I can clone the sender out here to prevent potential dead lock
for communicating asynchronously.
We can do this asynchronously though if you want it that way
I still believe there needs to be a dedicated channel
About a dedicated channel, do you mean an unified sender for all info we need to send to the core? I don't think it works well here to be honest
No description provided.