Confirmed users
431
edits
Line 5: | Line 5: | ||
So one very relevant question: do we even want to do this, given our move to using multiple processes (see [[Content_Processes]])? | So one very relevant question: do we even want to do this, given our move to using multiple processes (see [[Content_Processes]])? | ||
The API described on this page allows very limited necko access to non-main threads in our current, single process architecture. The primary target is an off-main thread HTML parser. But if we're going to switch to a multi-process architecture, with the HTML parser in the subprocess(es), there seems to be little point in doing this work, too. They both achieve better UI/parser response times, and greater parallelism. | The API described on this page allows very limited necko access to non-main threads in our current, single process architecture. The primary target is an off-main thread HTML parser. But if we're going to switch to a multi-process architecture, with the HTML parser in the subprocess(es), there seems to be little point in doing this work, too. They both achieve better UI/parser response times, and greater parallelism. The subprocess implementation will also expose a full necko interface to subprocesses, rather than the limited API here. | ||
The only reason I can see for doing the API here is because we can implement it sooner. But since there's just one of me :), it would mean the subprocess implementation would be delayed. | The only reason I can see for doing the API here is because we can implement it sooner. But since there's just one of me :), it would mean the subprocess implementation would be delayed. | ||
== API target: sending OnDataAvailable() to other threads == | == API target: sending OnDataAvailable() to other threads == |