1. Real world OS programming Nezer J. Zaidenberg

2.  Create process/thread  File and directory I/O  I/O multiplexing  Sync and locking  Access system logging  IPC  Communication

4.  In real life we rarely use system calls  Not portable  Not always most efficient  Handling error codes is hard  Take simple task – I/O multiplexing  Select  Poll  Pselect  Aio_read/write  Kaio_read/write (SUN)  Wait for single object (windows)  Wait for multiple object (windows)  …  Similarly for IPC – (sockets, file locking, SYS V IPC, POSIX IPC, message queues, RPC, CORBA, pipes, doors…)  What system call should we use?

5.  API is not identical in all Oss  Mmap is missing from Windows  Fork() becomes CreateProcess() etc.  Even when API is identical some options don’t work or ideal working method is different  flock don’t work in some cases with SYS V unix  Select don’t accept non-socket file descriptor on windows  Solaris threads work faster then POSIX threads on Sun

6.  We require several OO design pattern and services – some may not be available in all platforms other needs implementation every time  None blocking socket I/O  System logging  Dynamic library management  etc.

7.  Stability requires the code to be polished in all platforms (error handling, testing etc.)  Expendability requires usage of several design patterns (thread pool, etc.) – we cannot create process per connection  Common services (not provided by the OS in the exact format the application needs) to do I/O, time management directory management etc. are required.

9.  When same problems are encountered by group of people in the industry there is somebody suggesting a common solution  ACE – Adaptive communication environment  Academic effort became widely used  C++ based  ICE – Internet core engine  QT/rougewave etc. – commercial products  NSPR – netscape portable runtime  Home grown libraries by many organizations

10.  Based on C  Widely used in Firefox and other mozilla products  Open source  Good performance (almost everything is inline or macro)  Provide cross platform generic API

11.  In theory provide most efficient API for each platform  Usually takes care for all common error cases  Almost bug-free (so many users takes away most of the bugs)  Provide cross platform API  Provide design patterns we may not think about implementing

13.  NSPR is API is detailed in the 2 nd presentation (just display all hidden slides) and on the web  NSPR and such libraries still rely on the user to understand the basic mechanisms and basic system calls (though possibly not the newest interfaces.) so what we studied was not “just academic”  There are still many organizations that code using native APIs