The approach I'm now working on is using process spawning to avoid this problem.
Basically, I construct a separate process which creates a shared memory segment (QSharedMemory), and writes output to stdout. The shared memory segment is a data channel (containing the RGBA buffer for a QPainter), and stdout is the command channel (e.g. pick up freshly rendered content on this qrect).
The main process connects to this shared memory segment using QSharedMemory, and instantiates the process with QProcess.
Because I need Win32 compatibility, I need to suck the big one and create a new process every time a web page is spun-up - using a new QProcess instance. On unix, however, I believe that one could create one main process and call fork() every time a new web view is required. This would allow the parent process to do much of the setup work prior to forking, thus an efficiency gain. If you are on unix you may be able to use this approach.
Unfortunately, I can't see how Javascript can be viewed as a serious language - and I can't understand why this language is being chosen for the basis of QML. I only see a lot of pain for developers trying to get their systems reliable with that approach. Alternatively, they'll be back to forking processes for reliability and threading - back to early 1990's :)
-bms