Patent Application
20090327861
This Background is intended to provide the basic context of this patent application and is not intended to describe a specific problem to be solved.
In the network environment of modern computing, portable data, documents, and applications are ubiquitous. One component of creating truly portable data and documents for portable applications is that they are extensible. For example, the data and documents for portable applications should be easily customizable to add new functions and modify the behavior of existing functions for a wide variety of applications. Extensible Markup Language (XML) is an adaptable way to create common information formats and share both the format and the data across networks such as the World Wide Web and intranets. In a common scenario, developers may agree on a standard method to describe the information about a computer hardware component (e.g., processor performance, memory, etc.). The developers may then describe the component information format with XML. Standardizing the information description enables all users to send and retrieve data about the component or incorporate the component into various applications without specific knowledge of the component's description. Thus, XML can be employed to consistently and reliably share information.
XML is similar to Hypertext Markup Language, HTML, as both XML and HTML contain markup symbols to describe the contents of a page or file. XML, however, is not a markup language, but rather, a “metalanguage” used to create other specialized languages. XML provides an approach to define complex documents and data structures (e.g., invoices, molecular data, news feeds, glossaries, inventory descriptions, real estate properties, etc.). As long as the XML definition (i.e., the “schema”) for a collection of data is available, developers are able to create applications to reliably process any data formatted according to those rules.
I/O operations, such as reading from or writing to a disk, or other system calls, are typically employed to process digital documents, including XML documents. To process an XML document or other digital document, the execution threads that perform the processing operations of a computer are usually unable to complete any other document processing until an I/O operation completes. In other words, the threads required to process the XML document (e.g., XML process-specific threads, etc.) are blocked once I/O begins, and cannot continue processing until the I/O system thread returns. In the intervening period, the entire document processing operation is blocked by the kernel and cannot run, which may significantly delay execution or starve other XML processing threads.
Therefore, past methods for XML document processing that include I/O have had the unwanted effect of significantly limiting the scalability of XML document processing.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
Reader and writer XML processing APIs may process XML documents without blocking a thread by initiating any potential I/O necessary prior to reading from or writing to the XML processing API and by providing a callback which may be notified when the I/O, if any, is complete. The XML processing API may be able to simultaneously process multiple XML documents in various formats and sizes.
a and 3b may be an illustration of pseudo-code of a method for XML document read and write processing;
a and 4b may be an illustration of pseudo-code of another method for XML document read and write processing;
a and 5b may be another illustration of pseudo-code of yet another method for XML document read and write processing;
Although the following text sets forth a detailed description of numerous different embodiments, it should be understood that the legal scope of the description is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment since describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
It should also be understood that, unless a term is expressly defined in this patent using the sentence “As used herein, the term ‘______’ is hereby defined to mean . . . ” or a similar sentence, there is no intent to limit the meaning of that term, either expressly or by implication, beyond its plain or ordinary meaning, and such term should not be interpreted to be limited in scope based on any statement made in any section of this patent (other than the language of the claims). To the extent that any term recited in the claims at the end of this patent is referred to in this patent in a manner consistent with a single meaning, that is done for sake of clarity only so as to not confuse the reader, and it is not intended that such claim term be limited, by implication or otherwise, to that single meaning. Finally, unless a claim element is defined by reciting the word “means” and a function without the recital of any structure, it is not intended that the scope of any claim element be interpreted based on the application of 35 U.S.C. §112, sixth paragraph.
With reference to
The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180 in communication with the remote data source 190, via a network interface 170.
Computer 110 typically includes a variety of computer readable media that may be any available media that may be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. The ROM may include a basic input/output system 133 (BIOS). RAM 132 typically contains data and/or program modules that include an operating system 134, application programs 135 (e.g., an XML Processing Application 194), other program modules 136 (e.g., a general mechanism for performing asynchronous operations or an asynchronous operations API 196), and program data 137
The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media such as a hard disk drive 141 a magnetic disk drive 151 that reads from or writes to a magnetic disk 152, and an optical disk drive 155 that reads from or writes to an optical disk 156. The hard disk drive 141, 151, and 155 may interface with system bus 121 via interfaces 140, 150 and may contain data and/or program modules or storage for the data and/or program modules of the RAM 132 (e.g., an operating system 144, application programs 135 such as the XML Processing Application 194, other program modules such as the asynchronous operations API 196, program data 147, etc.).
Program data 137, 147 may include resources for the application programs and the other program modules, for example, a memory buffer 199 that may be filled by a read operation or flushed by a write operation to process an XML document, as will be further explained below. The buffer 199 may be a virtual memory space within some portion of computer memory. In some embodiments, the buffer 199 may be a contiguous or non-contiguous portion of volatile 132 or non-volatile memory 141, 151, 155, or a portion of a remote data source 190. The buffer 199 may also be shared between several components, including the read callback API 500 and the write callback API 550. Alternatively or additionally, the buffer 199 may be separate elements.
The XML processing application 194 and the asynchronous operations API 196 may also be components of the operating system 134, 144. The operating system 134, 144, may also include a process scheduler 198 that manages at least a portion of resources for the processing unit 120. For example, the computer 110 may execute only one process at any given time (e.g., processing I/O for multiple XML documents, etc.), using the scheduler 198 to guarantee that each executing process is given processing unit 120 time in sufficient quantities to keep executing. Each process running on the computer 110 may spawn individual tasks called execution threads, or simply threads. Some threads can spawn subordinate threads. It is common to have dozens, or even hundreds, of threads active at a given time. On the other hand, the computer may have a limited number of resources, such as disk storage or system or network I/O. Even though each resource may often support multiple threads, in many cases, a thread may have to wait for access to a given resource until a different thread releases it. In general, a number of threads may be spawned or created by a process scheduler 198 to perform processes (e.g., system I/O) as resources become available.
A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not illustrated) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A display device (not shown) may also be connected to the system bus 121 via an interface, such as a video interface.
An XML processing module 192 may be implemented as in integrated circuit or other form of hardware device connected to the system bus 121. The XML processing module 192 may process XML documents from the program data 137, 147, the remote data source 190, or other sources in the same manner as the XML processing application 194 and may incorporate the asynchronous operations API 196, as described below. In other embodiments, the XML processing module 192 is a component of another element of the computer system 100. For example, the XML processing module 192 may be a component of the processing unit 120, and/or the remote computer 180.
As previously discussed, processing multiple XML documents or large XML documents typically blocks an execution thread while the system performs I/O and significantly reduces XML document processing scalability.
To process an XML document 200 using the XML processing module 192 or XML processing application 194, a read API 300 (
The XML processing module 192 or XML processing application 194 may also incrementally process the XML document 200, one portion at a time. To incrementally perform XML document 200 processing, the read API 300 may consume or a write API 350 may write several portions of the XML document 200 and perform an I/O operation with each portion. In other words, the write API 350 may produce a series of bytes and the read API 300 may consume a series of bytes. These produced or consumed bytes may be written by the write API 350 and read by the read API at different times or may be transmitted over a communication protocol (e.g., TCP). The communication protocol may maintain the flow of bytes between the read API 300 and the write API 350. For example, while a write API 350 may write bytes of an XML document 200 to a TCP socket, a read API 300 may not necessarily be in communication with that socket. Similarly, a read API 300 may read bytes from a TCP socket, but the bytes may not necessarily be produced by a write API 350.
Using the XML document 200 as one example of a digital document that may be incrementally processed, the reader object 305 may read a start-tag 205 from a TCP socket and, concurrently, the writer object 355 may write a start-tag 205 into a system memory 130, a non-volatile memory 151, or other memory of the computer system 100. Both the read operation and the write operation may include an I/O operation that blocks a thread. Before encountering an end-tag 210, and while content elements 215 exist, the reader 305 may read content elements 215 and the writer 355 may write content elements 215 to memory as described above in relation to the start-tag 205. This “pull” method, where the write API 350 essentially pulls the XML document 200 data as it is needed, may block a thread until the entire XML document 200 is read and written into memory and I/O operations are complete.
With reference to
With reference to
With reference to
Thus, by incorporating one or more buffers 199 into which XML document 200 elements may be read to and written from by utilizing specialized “Fill” and “Flush” APIs, an XML document 200 may be processed while minimizing thread blocking caused by I/O.
With reference to
Upon invocation, the Fill API 510 may initiate an I/O operation and the read callback API 500 may be invoked once the I/O is complete (i.e., once the data is available). For example, a first read callback function 520 may be called once I/O is complete. The thread processing the XML document may then be further utilized after the Fill API 510 returns (i.e., the I/O is complete). For example, upon completion of the Fill API 510 and associated I/O (i.e., when the first read callback function 520 is notified), the function Read3A 520 may parse the start-tag 205 and verify that it is the expected start-tag 205 value.
Once the start-tag 205 is read into the buffer 19, the function Read3B 525 may be called to immediately continue processing the XML document. The reader object 505 may initialize a buffer 199 to a size 530. As previously described, the buffer 199 size 530 may be pre-determined or statically or dynamically determined based on an analysis of the XML document and, more particularly, based on the expected total size of the XML representation of the XML document content nodes 230. When the Fill API 510 completes any potential I/O, the read callback API 500 may initiate a second read callback function, for example, Read3C 535, and may read the content nodes 230 into the initialized buffer 199.
Once the second read callback function (Read3C) 535 completes reading the content nodes 230 into the buffer 199, the read callback API 500 may continue to read the end-tag 210 into a buffer 199 using callback function 545. The buffer 199 size and the amount read into the buffer 199 by the read callback API 500 may be pre-determined or statically or dynamically determined by analyzing the XML document. By providing the “Fill” API coupled with an asynchronous operations API 196, the XML processing thread may remain unblocked while the system, simultaneously and in parallel, processes multiple, arbitrary sized XML documents 200.
With reference to
Upon invocation, the Flush API 560 may initiate an I/O operation and the write callback API 550 may be invoked once the I/O is complete (i.e., once the data has been written). For example, a first write callback function 570 may be called once I/O is complete. The thread processing the XML document may then be further utilized after the Flush API 560 returns (i.e., the I/O is complete). For example, upon completion of the Flush API 560 (i.e., when the first write callback function 570 is notified), the function Write3A 570 may start writing the next element.
The writer object 555 of the write callback API 550 may write a start-tag 205 and initiate the Flush API 560 to write the buffer 199. In some embodiments, a first write callback function 570 may also be called by the Flush API 560 when the I/O is complete without blocking the XML document processing thread or otherwise waiting for the I/O to complete. For example, upon completion of the Flush API 560 (i.e., writing the start-tag 205 from the buffer 199), the function Write 3A 570 may be called. In short, XML document processing may continue without being idle until the write callback API 550 completes. Other instances of the write callback API 550 may continue to write multiple XML documents 200 to memory while other XML document processing operations continue.
The function Write3A 570 may continue to write the content nodes 230 to the system 100 memory. Once the Write3A 570 function (i.e., the write callback function) completes writing the content nodes 230, the write callback API 550 may continue to write the end-tag 210 out of a buffer 199570. The buffer 199 size and the amount written out of the buffer 199 by the write callback API 550 may be pre-determined or statically or dynamically determined by analyzing the XML document. By providing the “Flush” APIs coupled with an asynchronous operations API 196, the XML processing thread may not be blocked while the system, simultaneously and in parallel, processes multiple, arbitrary sized XML documents 200.
With reference to
The method 600 may describe an efficient, non-blocking mechanism for incrementally processing arbitrary sized XML documents. At block 605, a computer 110 may receive an arbitrary sized digital document 200. In some embodiments, the document 200 is an XML document including a start-tag 200, an end-tag 205 and an arbitrary number of content elements 215 each including an element start-tag 220, an element end-tag 225, and content node 230. Of course, any digital document including encoded text or other content to control its structure, formatting, or the relationship among the document's parts may be processed by the method 600.
At block 610, the method 600 may read the start-tag 220 into a buffer 199. In some embodiments, the block 610 may initiate a Fill API 510. For example, the Fill API 510 may include initializing a buffer 199 that is sized according to an expected size 515 of an XML document 200 start-tag 205 or other element that signals the beginning of a digital document. As previously described, the size 515 of the buffer 199 may be determined statically or dynamically to optimize XML document 200 processing or to minimize any obstruction in XML document processing. Some examples of XML document obstructions, malicious or not, include start-tags 205 or other XML document 200 elements with large amounts of white space, unnecessary characters or elements that cannot be parsed, other malicious techniques, or unintended or intentional errors by the document 200 author or another party. The buffer 199 may be a virtual memory space within some portion of computer memory. In some embodiments, the buffer 199 may be a contiguous or non-contiguous portion of volatile 132 or non-volatile memory 141, 151, 155, or a portion of a remote data source 190. The buffer 199 may also be shared between several components, or may be separate elements that are in communication.
Upon initializing the buffer 199 and completing an I/O operation including the start tag 200, block 610 may also initiate a first read callback function 520. In some embodiments, the first read callback function 520 is facilitated by an asynchronous operations mechanism 196 and any potentially asynchronous operation may provide a callback function to invoke when a previous operation is complete. For example, the first read callback function 520 may be invoked when the asynchronous operation of block 610 is complete. The XML document processing thread may, therefore, continue immediately without being blocked and multiple XML documents 200 may be processed. The first read callback function 520 may read the start-tag 205 into the buffer 199 or another function to facilitate XML document processing.
At block 620, the method 600 may perform an I/O operation by reading the content nodes 230 of the XML document 200 into the buffer 199. In some embodiments, block 620 may utilize a function 525 to initialize or re-initialize a buffer 199 and read the content nodes 230 into the buffer 199. For example, the function 525 may include the Fill API 510 as described above in relation to block 610 as well as instructions to initialize the buffer 199 to a size as described above. Without blocking a thread processing the XML document, the method 600 may begin a second read callback function 535 upon completion of the I/O operation. The second read callback function 535 may include a conditional loop of instructions such that, so long as the XML document 200 includes a content node 230 surrounded by an element start-tag 220 and an element end-tag 225, a content node 230 may be read into the initialized or re-initialized buffer 199. Else, the second read callback function 535 may proceed to processing the XML document 300 end-tag 210.
At block 630, the method 600 may read an end-tag 210 of the XML document 200 into the buffer 199. In some embodiments, block 630 may utilize a function 540 including a third read callback function 545 upon completion of an I/O operation, for example, initializing or re-initializing a buffer 199 and reading the end-tag 210 into the buffer 199. For example, the fourth read callback function 540 may, after initializing the buffer 199 to a size as described above, begin the third read callback function 545.
At block 640, the method 600 may determine if another digital document is available for processing. In some embodiments, the method 600 receives a second XML document 200 or other digital document that may be processed. If, at block 640, the method 600 determines another document needs to be processed, then the method 600 returns to block 605. If the method 600 determines that no other documents are available for processing, then the method may end or wait until another XML document becomes available.
The method 700 may also describe an efficient, non-blocking mechanism for incrementally processing arbitrary sized XML documents. At block 705, a computer 110 may receive an arbitrary sized digital document 200. In some embodiments, the document 200 is an XML document including a start-tag 200, an end-tag 205 and an arbitrary number of content elements 215 each including an element start-tag 220, an element end-tag 225, and content node 230. Of course, any digital document including encoded text or other content to control its structure, formatting, or the relationship among the document's parts may be processed by the method 700.
At block 715, the method 700 may complete an I/O operation by writing a start-tag 205 into memory. In some embodiments, a writer object 555 writes the start-tag 205 to a portion of the system memory. The writer object 555 may then initiate a Flush API 560 to write the buffer 199 and to initiate an I/O operation to write the start-tag. Without blocking a thread processing the XML document, block 715 may also initiate a write callback function 570 upon completion of the I/O operation.
At block 725, the method 700 may write the content nodes 230 to the system memory or other component as dictated by I/O operation. In some embodiments, the content nodes 230 may be processed from the buffer 199 to the system memory. For example, the write callback function 570 may be invoked upon completion of the I/O operation and include a conditional loop of instructions such that, so long as the buffer 199 includes a content node 230 surrounded by an element start-tag 220 and an element end-tag 225, a content node 230 may be written to the system memory using a function 575. Else, the write callback function 570 may proceed to processing an end-tag 210.
At block 735, the method 700 may complete another I/O operation by writing the end-tag 210 to the system memory. In some embodiments, the end-tag 210 may be processed from the buffer 199 to the system memory by the function 580. For example, the function 580 may include an instruction to write the end-tag to the system memory using the Flush API 560. The function 580 may clear the buffer 199 initialized at block 630.
At block 740, the method 700 may determine if another digital document is available for processing. In some embodiments, the method 700 receives a second XML document 200 or other digital document that may be processed by the I/O system thread. If, at block 740, the method 700 determines another document needs to be processed, then the method 700 returns to block 705. If the method 700 determines that no other documents are available for processing, then the method may end.
Thus, documents in a digital format, such as multiple XML documents, may be processed simultaneously and in parallel by the computer system 100 using a reader callback API 500, a writer callback API 550, and employing asynchronous I/O techniques without blocking threads that process the XML documents.
Much of the inventive functionality and many of the inventive principles described herein are best implemented with or in software programs or instructions and integrated circuits (ICs) such as application specific ICs. It is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein may be readily capable of generating such software instructions, programs, and ICs with minimal experimentation. Therefore, in the interest of brevity and minimization of any risk of obscuring the principles and concepts in accordance to the present invention, further discussion of such software and ICs, if any, may be limited to the essentials with respect to the principles and concepts of the preferred embodiments.
