As already mentioned, an application that exploits the Workplace Shell consists of a number of objects on the desktop or in folders, which interact with one another to carry out operations as requested by the user. The implementation of the Workplace Shell under OS/2 V2.0 causes all Workplace Shell objects to run in a single process, under the control of the Workplace Shell itself. It is therefore possible for an error in a Workplace Shell to terminate the Workplace Shell process, and all objects currently open under the control of that process. While the Workplace Shell automatically restarts itself and its open objects, it is recommended for reasons of performance that applications carrying out lengthy processing such as database or remote system access should be implemented using multiple processes. Other processes in the system are not affected if the Workplace Shell process terminates, and become available to the user as soon as the shell restarts itself, without the need to reload application code, reinitialize communications links, etc.
For example, a database query application that searches a database for customer records and displays these in a Workplace Shell folder may be composed of two processes, each with multiple threads, as shown in Figure "Workplace Shell Application Structure."
The requester portion of the application, which allows the user to enter a query, and which displays the results on the screen, is implemented as a Workplace Shell object, running under the control of the Workplace Shell process. The primary thread in this process carries out the interaction with the end user, while a secondary thread is created to handle communication between processes.
The second process acts as a database server, and is created by the first process when the application is started. The server process has a primary thread that accepts requests from the requester in the Workplace Shell process, and a number of secondary threads that actually perform the database access.
If an errant object or application were to cause the Workplace Shell to terminate, the requester threads would be terminated. However, the server process would not be terminated, and communication with the requester could be re-established simply by having the requester initiate one of the standard interprocess communication mechanisms described in Multitasking Considerations.