Threads in SeaMonkey
Comments to: xpfe newsgroup.
This document describes the thoughts on threading issues for SeaMonkey and beyond. This is a preliminary design proposal and outcome of a meeting that was held this week.
Threads in SeaMonkey
The current plan for 5.0 for all major platforms (Windows, Mac, Unix) is to have one UI thread and one or more netlib threads. Processing that occurs in the UI thread includes, parsing, Creation of Content model, layout, DOM activity, incremental & resize reflows, UI event loop, callbacks and plugins. The netlib threads are responsible only for network activities. All the major platforms use NSPR module to create the threads. There are 2 things about using NSPR to create and manage threads that should not be confused.
- To Use the NSPR threads API
- To Use, user level threads created by NSPR or to use native platform threads created for you by NSPR.
All platforms use the NSPR APIs to create their threads for the obvious reason of portability, but not all platforms use NSPR user threads. The issues are described in the next section. You can learn more about NSPR here
Platform Issues
One of the main concerns that were raised in the meeting was, platform support for multiple UI threads and the possibility of having multiple UI threads.
Unix
Unix, currently supports only one UI thread because the underlying libraries Xlib, gtk, Xt, motif are not thread safe. Any situation that necessitates multiple threads to access the X libraries (like Java) has to go through a locking mechanism that will make sure, only one thread accesses X at any given time. This is the solution, communicator versions 2+ have used. The granularity of the lock is a key factor in deciding which threads to use. NSPR user threads or Native threads. ? Unix Communicator 4.5 uses NSPR user threads and the XLock mechanism is tightly integrated in NSPR.
Threads in unix for 5.0
For 5.0 the current consideration is to continue to use NSPR user threads for 1 UI thread one or more netlib threads to take care of the above situation with Java or any other plugin that may access the X libraries.
Threads in unix beyond 5.0
The Unix team is however very keen in moving the Xlock mechanism out of NSPR to a higher level. This will enable unix to use Native threads (which is pthreads in most platforms) which has other developmental advantages like easy to debug, ability to interact with other software components etc.... This will also enable unix to have multiple NSPR UI threads with their own nsGUIEvent message pumps and all access to the underlying X/rendering layer controlled through the Xlock. The unix team may consider moving the xlock out of NSPR for 5.0 depending on how OJI will live in SeaMonkey. To learn more about the Xlock issues and java, you can look here.
Windows
Windows is inherently capable of having multiple UI threads and a native event loop per thread. Though this is a great advantage, its usage with other modules of SeaMonkey which are not currently thread safe is in question. In order to have the model where each toplevel window runs in its own thread, we need to have most of the webshell interfaces, DOM, XPFE widgets, to be thread safe and we are not there yet.
Threads in windows for 5.0
So, considering all the new work that needs to be done to get to this mode, for 5.0, windows will also support only one UI thread for the complete application and multiple netlib threads. Windows will use the NSPR threads API to create native threads for its needs.
Mac
The current implementation, and future plan for threading on Mac OS lies with NSPR threads. The Mac implementation of NSPR threads is a user level and non preemptive. It does not rely upon the Mac OS Thread Manager. Should it ever become advantageous and plausible to utilize pthreads on top of Mach in System X, or the Thread Manager as the implementation of Mac OS NSPR threads, the issue can be revisited.
Since NSPR threads on Mac OS are not preemptive, it allows us to control reentrancy and locking issues more easily. In short, the fact that many Mac OS Toolbox calls are not thread safe can be dealt with by choosing carefully what to lock, and where to yield control of a thread for a possible context switch.
Performance of Threads on Mac OS
How well threads perform on Mac OS vs. other, preemptive platforms depends largely upon how effectively yield calls are placed in code. On a preemptive system, a yield call may either be a no-op or a true yield (I'm not sure off the top of my head what it is in NSPR for Win and Unix).
The NSPR thread scheduling policy for Mac OS threads can also be adjusted to give preference to threads which have events pending in their event queues for lower event response latency.
NSPR file I/O on the Mac can be better integrated with NSPR threads to provide better performance. For example, a thread that was blocked on file I/O but is now ready to run can be giving a higher priority in the scheduling policy. This is commonly done on some unix systems to improve I/O performance. Also, NSPR file I/O can do speculative look ahead buffering to improve the performance of sequential file reads of the same byte size. This sort of operation is very common throughout the code base. Speculative read ahead buffering allows the sequential file reads of the same or smaller size to return immediately without doing a context switch. I have many of these changes that I made during the Gromit project but never checked in. I'm planning on giving Wan-Teh and the NSPR team these changes Real Soon Now for possible integration.
Threads on Mac OS in Netscape 5.0
Mac OS will have just as many NSPR threads as other OSes, one UI thread, and one or more NetLib threads. Very little will be different on Mac OS than any other platform in this model other than their non-preemptive nature.
Threads on Mac OS beyond 5.0
In the future if we have more UI threads, code can be added to have event dispatching from the Mac application's main event loop to the proper thread event queue. This sort of marshaling would allow the Mac OS platform differences to be further abstracted out, and more code to be written in an XP fashion. Again, performance concerns could be addressed within the Mac OS NSPR thread scheduler.
Modal Dialogs:
The current proposal to implement modal dialogs is this setup is to have a mutex that will allow layout module to finish up any layout or reflow operation that may be in progress and then bring up the Modal dialog. As long as the modal dialog is up, layout will interact only with it.