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 Do we actually want to implement this even worth implementing given our plans for multiprocess? ==
So one very relevant question: do we even want 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 do this, given our move proxy the data to using multiple processes the main thread. The benefits are greater parallelism and reduced interference between the main thread and the parser thread (see [[Content_Processes]]resulting in better UI responsiveness)? .
The API described on this page allows very limited necko access to non-main threads in our currentNow that we are moving towards using multiple processes (see [[Content_Processes]]), single process architecturethere is some question of how useful the solution documented here is. The primary target is an off-main thread In the long run, we are going to be putting the HTML parserin separate processes rather than threads; so this solution is at best a temporary one. But if we're going since the API here should be faster to switch to a implement than the multi-process architecture, with the HTML parser in the subprocess(es)one, there seems to it might be little point in doing this work, too. They both achieve better UI/parser response times, and greater parallelism. The subprocess a useful stopgap implementation will also expose for a full necko interface to subprocessesrelease or two, rather than the limited API hereuntil multi-process is ready for prime time.
The only reason I can see for doing the API here key question, then, is because we can implement it sooner. : But since there's just one of me :)how much performance/responsiveness benefit do we anticipate getting from eliminating proxied network receives, it would mean and having the subprocess implementation 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 delayedappreciated.
== API target: sending OnDataAvailable() to other threads ==
