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.
== Do we actually want to implement this, or wait for multi-process necko? Goals ==
The basic goal here is to Goal: allow the off-main-thread HTML 5 parser to get data from the network without having to proxy the data from the main thread. The benefits are greater parallelism and reduced interference between the main thread and the parser thread (resulting in better UI responsiveness).
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 Benefits: greater parallelism and reduced interference between the long run, we are going to be putting main thread and the HTML parser thread (resulting 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 timebetter UI responsiveness).
The key question, then, Note that this isonly useful for single-process Gecko (non-electrolysis): just how much performanceat least until IPDL supports sending/responsiveness benefit do receiving on non-main threads, we anticipate getting from eliminating proxied network receives, and having will always need to use the HTML 5 off-main 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 appreciatedwhen multiple processes are used.
== API target: sending OnDataAvailable() to other threads ==
