Handles versus File Descriptors

STDLIB provides a POSIX-like abstraction of file descriptors which unifies the different types of resource and permits a single API to be used across all of them. This is a significantly different approach from Win32 and the Symbian platform, both of which have separate APIs for each distinct type of resource.

STDLIB supports files stored in the file system, sockets, a console, and a /dev/null device. The first time STDLIB initialises its internal file descriptor table it creates an emulated console device and attaches it to descriptors 0, 1 and 2. The emulated console device will appear as a window when it is first used (i.e. when the program writes to or reads from the console).

The open() function recognises the following names:

• CON: is taken to mean a newly-created console. This will never be the same console as the one automatically associated with 0, 1 and 2.

• NUL: is taken to mean a /dev/null device.

• TMP: is taken to mean a temporary file, which will use the underlying Symbian platform file system facilities to create a uniquely-named temporary file, and will cause the file to be deleted after it has been closed cleanly.

• COMx: is the serial port where x is a number from 1 to 9. COM1: corresponds to serial port zero and so on.

• IRCOMx: is the serial port where x is a number from 1 to 9.

The number of open files in the file has no explicit limit.

The Symbian platform resources such as RFile and RSocket are derived from class RSubSessionBase, so are thread specific. This means they cannot be used by any thread other than the one which opened them. In STDLIB however, the CPosixServer, if running, controls the master file descriptor table. In this case, all STDLIB threads in a process may share their resources, because the STDLIB implementation forwards all I/o requests to the resources owned by that process's CPosixServer thread. If no CPosixServer is running, each thread has a separate file descriptor table and the resources are not shareable.