by fddima » Wed Apr 12, 2017 8:08 am
@emerick custom communication channel implies to work in parallel to standard communication channel, and gives you ability to do remote execution in any fashion (sync/async). But don't let fool self: "server" at renderer side most likely accept messages on separate thread, and now you will need to solve same synchronization problem: we executes on one thread, but want to do job on another thread (usually on renderer thread). So post message & wait can help (I'm leaving v8 context tricks aside.) From client perspective you anyway need post message to custom communication channel & wait.
So, as you see (at client side): you anyway need send something & wait. The only difference that blocking of any CEF threads will not block custom communication channel. But problem & actions are exactly same.
So, i'm more likely to turn question in other direction:
1. If you job (in browser process) executed on own thread (non CEF) then you can safely post message & wait.
2. If you job executed on CEF thread for some reason - then you there need true asynchronous code (may be based on continuations).
I'm think that it should be much easier to use (1) or (2) just because you not need in complex custom channel machinery: i'm believe custom channel will be much harder than dispatch your jobs onto separate threads and wait (async) results.
I.e. from my understanding: you not need true synchronous access, you only need sync fashioned calls => to utilize CEF-provided IPC you should not block CEF threads => you job should executed on non-CEF thread to able wait result. This is still too hard to implement?