The Background of the XP Event Loop
Last Modified: 8-31-99
Up until now any one needing to provide a native event loop in SeaMonkey has had to write one on their own. There are a number of places virtually every application ends up needing a native event loop in some form of another. In most cases the main() for the application has one, but then other portions of complex apps may as well (UI threads, modal dialog windows, native event message peeking, etc.). Not only is this code not cross platform, but it can often be quite difficult to write in a XP bug free manner.
As the SeaMonkey development effort has progressed there have been a growing number of places that native event loops have been either implemented or needed (At last count around 13). In most cases the code implements the Windows loop, comments the Mac for later implementation and uses PLEvents for Linux. So over the past couple of weeks, as I was about to need to implement yet another one, a number of us discussed this issue and decided the best course of action was to bite the bullet at this stage and provide a clean fully featured service that would abstract native event loops allowing users to write to this new XP Event Loop. We will at that point take all the current places in the code that implement their own event loop and will have them rely on the new centralized XP Event Loop.
Just to clarify, there has been some work in this
area. nsAppShell has been used by many people who wished to run a
native event loop but didn't want to write it themselves. In fact
much of the initial implementation for the XP Event Loop will be taken
from nsAppShell. There are a few reasons for going on and creating
the XP Event Loop. First of all nsAppShell is not exposed through
XPCOM and is not a public interface. This is obviously a barrier
to re-use. Secondly AppShell was not setup to handle all the different
event loop types that you may encounter and need from an application stand
point. Thirdly this code was in widget, yet the XP Event Loop is a basic
service that should be provided so others can simply grab the XPCOM layer
and it's NSPR dependency and then build an application. So the idea
was to come up with a new set of interfaces that could live at a low level
as a foundation from which to build applications.