Multiprocessing Firefox

With newer, modern hardware systems, it is likely that they will contain either multiple physical processors or a single physical processor with multiple cores. When writing applications with these systems as the target platform, it is often a good idea to utilize more than a single process within the application. Why is it that multiple processes make sense within a single application? One may be inclined to think of the concept of a process as being designated for a single running application, or a one-to-one cardinality if you will. On top of moving away from the comfortable idea of a single process for a single application that so many developers are used to, there is also the messy problem of inter-process communication. This particular problem isn't quite as bad as it is made out to be. We just need to use the appropriate abstractions on top of the inter-process communication functionality. Going back to the question of why it is a good idea in the first place, the chief benefit of using multiple processes within a single application is the performance gains. While the same application concurrency logic implemented using threads will offer better responsiveness, the multiprocessing approach offers an opportunity for true concurrency on systems with multiple processors.

The Firefox web browser is currently implementing a version of the browser which incorporates multiple processes rather than having the entire application run in a single process. As discussed above, this entry provides some rationale behind why the development team decided to implement this functionality. Aside from the inherent performance gains offered by systems with multiple processors, there is increased stability. The stability is increased because independent processes decouple the entire browser architecture. This helps provide a degree of isolation not available in a single process. The stability gains are especially apparent when considering the multiple tabs used to view disparate web pages. Security could potentially be improved as a side effect of the isolation provided by processes. Finally, not mentioned in the entry but equally relevant in design terms, the distribution of responsibilities within the web browser system becomes very clear. It sometimes takes a drastic move to improve this design principle such as moving entire pieces of code to a separate process.

In this entry, a demonstration of the browser running a separate process for the tab content shows a clear stability improvement. Even after killing the content process, the user interface process remains in tact.

Python BaseHTTPRequestHandler Request Parsing

When a client sends an HTTP request to a server, that request is sent as a raw string of HTTP request data. Each component of the HTTP request, while in the transit state, is still considered a single monolithic component. This raw HTTP request must be parsed. It is the parsing action that transforms this raw HTTP request string into a coherent set of HTTP request components. Python provides a module in the standard distribution that provides basic HTTP request parsing capabilities. The class used for this is called BaseHTTPRequestHandler. As the name suggests, it is the most basic of all HTTP request handling capabilities provided by Python and must be sub-classed to carry-out any meaningful functionality. What we are interested in here isn't such much the extending of the BaseHTTPRequestHandler class as much as how the HTTP request parsing of the class is broken down. This fundamental action of web programming in Python is rarely seen because many web application frameworks do this for us. Even when using the fundamental BaseHTTPRequestHandler class, developers need not concern themselves with parsing individual HTTP requests. This is also taken care of by the class as a step in the request handling activity. It is useful, however, to see how the most fundamental HTTP request parsing functionality works and if there are any weaknesses with the approach.

The following is an illustration of how an HTTP request is parsed by the BaseHTTPRequestHandler class. Keep in mind, this is only a high-level view of what actually happens. There are many smaller steps kept out of the illustration for simplicity.



One question to ask here is if any of these actions can be parallelized. One candidate might be the initialization of the HTTP headers. The reason being, there is no prerequisite input to the header initialization that isn't available before the actions previous to the header initialization are executed. Suppose this action were carried out in a new thread, would there really be any significant performance gain. Unlikely. Is it an alternative design worth exploring? I would think so. See below for an illustration of the header initialization executing in parallel with the other HTTP parsing actions.