The fact that each has its own thread right now is an implementation bug, and I am definitely in favor of fixing that. Having multiple threads right now is pointless since all the v8 resolvers share a global isolate and lock execution to that anyway, so doing so from distinct threads is pointless. That said I recall it was only 1 or 2 instances we ended up with.

So a single thread SGTM!

Re-thinking the threading beyond that depends on the clients of the newfangled network service and their expected use-case. For Chrome a single thread and V8 isolate is a good memory tradeoff. However if the network service were being used with lots of different contexts and PAC scripts and we wanted higher throughput and CPU utilization, then being able to run multiple PAC scripts in parallel could be an advantage.

As for running v8 on the thread receiving the mojo call, would that the preclude being able to run this in an in-process mode? Or do mojo services get run on a dedicated thread already?

One thing relating to robustness (will have this issue either way) is the possibility of hangs. Running the PAC script involves running user-controlled script, which may not terminate. This is something we may want to address in the service model, or accept that one caller's independent script may hose the whole service.

A mojo service would not need to receive proxy resolution calls on the service thread - it can just create another thread, and run all mojo calls there.  So regardless of whether there's one mojo serve thread, or 5 dozen, it doesn't really matter much to whatever decision we make here, just potentially adds a little complexity to startup/shutdown.

I hadn't thought at all about hangs.  I guess we already kinda have that issue, in that we could keep hanging PAC resolvers around.  THey won't hang the service, but will hang all network requests for a context until a new resolver is created, and even then, they'll continue to consume 100% CPU time.

A hang today will hang all proxy resolutions (since even though we have a thread per ProxyResolverV8TracingImpl, we lock access tot he same v8 isolate). So not a new problem. Only thin I think differs is the expectation of independence when we name things a "service".

Hanging is I would say is an orthogonal problem. One approach would be to setup a watchdog timer in-process that terminates execution of the V8 isolate (although have had problems with this messing up v8 state in the past), or suicide the whole process. Or have the caller restart the service if it is unresponsive to requests.

 Issue 174807  has been merged into this issue.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot