Understanding CEF 1 threading model

[nmuzaffar]

I've read enough of the Chromium Design Documents to understand their multi-process archictecture. I understand that CEF 1 is currently under a single process model. But I'd to confirm hMaow it actually manages its threads (ie I/O thread, in UI Thread and Renderer threads). I was able to find a very small blurb about the single process model in the Chromium documentation [1]. If CEF employ's Chromium's single process model, then I'd like to confirm if these threads the same as they would their multi-process architecture [2]. If all this explained somewhere already, I'd appreciate it if you can just point me to the resource.

Hoping that understanding how threads are initialized, communicate, and managed in CEF currently, will help me understand a deadlock situation that I experienced.

Thanks for the help,
Nadir

1. http://www.chromium.org/developers/desi ... le-process
2. http://www.chromium.org/developers/desi ... chitecture

[magreenblatt]

See CefContext::Initialize(), CefContext::Shutdown() and cef_process.[h|cc] for an understanding of the CEF1 threading implementation.

[fddima]

My methodology it is very simple not only about CEF, but elsewhere:
CEF maintains 3 threads: UI, IO, File.
CEF API documentation says for calls from which thread it is allowed, and for handlers from which thread it will be called. If it is not defined - mainly it is documentation bug, but often it is handler-specific (i.e. IO only) or world-wide (usually UI).

And, if you read html 5 spec you will see, that in fact HTML can be parsed only from UI thread, same on only this thread can be executed JS, 'cause it is part of html parsing process. As result actual rendering (not just bit-blitting, but huge processing of dom and rendring tree) is possible only from same UI thread. In fact, only IO tasks can be executed concurrently or some special parts like web workers (they have strong contract with 'main' (UI) thread). Of course, may be tens years ago this is will be not true, but currently there is a natural software problem - but in our time, often masked by multi-process paradigm with security flag -- but this is full rubbish. This is 'cause big three (four) - it is very not simple, but single threaded layouting engines by desing (layouting engine it is very huge huge huge work, i do not believe that they can be made better, without changing html/core feats).

About deadlocking - when client code have many synchronization contexts - you always can got deadlock, when you do not design client code properly.
I.e. we have two commands (of sync context) - it is post -> just queue task for execution on some thread (it is supported natively in CEF and it is enough).
Second command it is 'Send' -> it is Post & wait for reply.
Thread1: Send to Thread2
Thread2: Send to Thread1
Very simple deadlock. In fact "call graph" can be more complex, 'cause client application also can use own threads, and final call graph distributed across many threads. Hard to debug.
My suggestion to develop client code is only one: try do not do assumptions on thread where you call in client code, and always do debug/release checks when specific thread required (i not mean that you need re-check thread from which CEF call handler).
But good news - in 99% you need sync only with Main/UI thread. Then IO thread, but it is actual for example for handling custom scheme, but this is much more simplier/determined, and transparent to UI.

PS: Sorry, for bad english, may be some of my thinks stays not understandable.