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.