254
edits
Platform/XML Rewrite: Difference between revisions
content: on the main thread
(content: on the main thread) |
|||
| Line 54: | Line 54: | ||
class mozilla::parser::xml::AExpatHandler { | class mozilla::parser::xml::AExpatHandler { | ||
virtual void RegisterCallbacksInto(XML_Parser aParser) = 0; | virtual void RegisterCallbacksInto(XML_Parser aParser) = 0; | ||
} | }; | ||
====Dealing with stream data off the main thread==== | ====Dealing with stream data off the main thread==== | ||
| Line 67: | Line 67: | ||
Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. | Instead of parsing a special file in this case, expat should be hacked in such a way that its internal entity tables can be mutated to a state that's equivalent with the state they'd end up in by parsing the special DTD without actually parsing anything. | ||
====Lack of actual speculation==== | |||
In the HTML case, the only thing that can cause a speculation fail is document.write. Since XML has no document.write, the off-the-main-thread XML parser can parse its input to completion and doesn't need to support stream rewinding. All the tree ops can be queued up and they just need to be executed in chunks that end at a script execution op so that the world experienced by scripts looks as though the parts of the document after the current script didn't exist yet. | |||
==Parsing chrome: content== | |||
Chrome documents in Firefox are localized using external DTDs that define named entities. This needs to work with the new implementation. Since initiating DTD IO from off the main thread is trouble, chrome: documents should be parsed on the main thread. To enable this, there should be an on-the-main-thread alternative for mozilla::parser::xml::StreamParser: mozilla::parser::xml::MainThreadStreamParser. To get assertions about which methods should run on which thread right, it is probably useful to actually have two classes instead of having one class with a flag that picks different code paths within the class. The two classes should probably share encoding sniffing code in a common superclass. | |||
Since chrome: documents can be XHTML, it follows that mozilla::parser::xml::TreeOpGenerator needs to work on the main thread, too. This shouldn't be a big deal considering that tree op generation in the HTML case can run on either thread. | |||