Necko: support sending OnDataAvailable() to other threads: Difference between revisions

Necko: support sending OnDataAvailable() to other threads (view source)

Revision as of 19:15, 6 May 2009

274 bytes added , 6 May 2009

→‎Is this even worth implementing given our plans for multiprocess?

Jduell

Confirmed users

431

edits

@@ Line 1: / Line 1: @@
 At the April 2009 Platform work week we had a meeting on making necko support requests from threads other than the main thread.  Here's some design notes on what we came up with.
-== Is this even worth implementing given our plans for multiprocess? ==
+== Do we actually want to implement this? ==
-So one very relevant question:  do we even want to do this, given our move to using multiple processes (see [[Content_Processes]])?
+The basic goal here is to allow the off-main-thread HTML 5 parser to get data from the network without having to having to proxy the data to the main thread.  The benefits are greater parallelism and reduced interference between the main thread and the parser thread (resulting in better UI responsiveness).
-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.
+Now that we are moving towards using multiple processes (see [[Content_Processes]]), there is some question of how useful the solution documented here is.  In the long run, we are going to be putting the HTML parser in separate processes rather than threads;  so this solution is at best a temporary one.  But since the API here should be faster to implement than the multi-process one, it might be a useful stopgap implementation for a release or two, until multi-process is ready for prime time.
-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 key question, then, is:  just how much performance/responsiveness benefit do we anticipate getting from eliminating proxied network receives, and having the HTML 5 off-thread parser get reads directly?   If this is not a significant win, I'd prefer to focus my attention on developing multiprocess networking.
+Thoughts on this matter would be appreciated.
 == API target:  sending OnDataAvailable() to other threads ==