In computing, the Netscape Portable Runtime, or NSPR, a platform abstraction library, makes all operating systems it supports appear the same to (for example) Mozilla-style web-browsers. NSPR provides platform independence for non-GUI operating system facilities. These facilities include: threads thread synchronization normal file and network I/O interval timing and calendar time basic memory management (malloc and free) shared library linking. Much of the library, and perhaps the overall thrust of it in the Gromit environment, provides the underpinnings of the Java virtual machine, more or less mapping the sys layer that Sun defines for the porting of the Java VM to various platforms. NSPR does go beyond that requirement in some areas, as it also functions as the platform-independent layer for most of the servers produced by Netscape. History The first generation of NSPR originally aimed just to satisfy the requirements of porting Java to various host environments. NSPR20, an effort started in 1996, built on that original idea, though very little remains of the original code. (The "20" in "NSPR20" does not mean "version 2.0" but rather "second generation".) Many of the concepts show reform, expansion, and maturation. In 2009, NSPR still functioned appropriately as the platform-dependent layer under Java, but it also served in supporting clients written entirely in C or in C++. How it works NSPR has the goal of providing uniform service over a wide range of operating-system environments. It strives not to export the lowest common denominator, but to exploit the best features of each operating system on which it runs, while still providing a uniform service across a wide range of host offerings. Threads Threads feature prominently in NSPR. The software industry's offering of threads lacks consistency. NSPR, while far from perfect, does provide a single API to which clients may program and expect reasonably consistent behavior. The operating systems provide everything from no concept of threading at all up to and including sophisticated, scalable and efficient implementations. NSPR makes as much use of what the systems offer as it can. NSPR aims to impose as little overhead as possible in accessing those appropriate system features. Thread synchronization Thread synchronization loosely depends on monitors as described by C. A. R. Hoare in "Monitors: An operating system structuring concept", Communications of the ACM, 17(10), October 1974 and then formalized by Xerox' Mesa programming language ("Mesa Language Manual", J.G. Mitchell et al., Xerox PARC, CSL-79-3 (Apr