Processes

Multi-tasking in 4D is the ability to have distinct database operations that are executed simultaneously. These operations are called processes.

Multiple processes are like multiple users on the same computer, each working on his or her own task. This essentially means that each method can be executed as a distinct database task.

This section covers the following topics:

• Creating and clearing processes
• Elements of a process
• User processes
• Processes created by 4D
• Local and global processes
• Record locking between processes

Note: This section does not cover stored procedures. See the Stored Procedures section in the 4D Server Reference manual.

There are several ways to create a new process:

• Execute a method in the Design environment after checking the New Process check box in the Execute Method dialog box. The method chosen in the Execute Method dialog box is the process method.
• Processes can be run by choosing menu commands. In the Menu Bar editor, select the menu command and click the Start a New Process check box. The method associated with the menu command is the process method.
• Use the New process function. The method passed as a parameter to the New process function is the process method.
• Use the Execute on server function in order to create a stored procedure on the server. The method passed as a parameter of the function is the process method.
• Use the CALL WORKER command. If the worker process does not already exist, it is created.

A process can be cleared under the following conditions. The first two conditions are automatic:

• When the process method finishes executing
• When the user quits from the database
• If you stop the process procedurally or use the Abort button in the Debugger
• If you choose Abort in the Runtime Explorer
• If you call the KILL WORKER command (to delete a worker process only).

A process can create another process. Processes are not organized hierarchically—all processes are equal, regardless of the process from which they have been created. Once the “parent” process creates a “child” process, the child process will continue regardless of whether or not the parent process is still executing.

Each process contains specific elements. There are three types of distinctly different elements in a process:

• Interface elements: Elements that are necessary to display a process.
• Data elements: Information that is related to the data in the database.
• Language elements: Elements that are used procedurally or are that are important for developing your own application.

Interface elements consist of the following:

• Menu bar: Each process can have its own current menu bar. The menu bar of the frontmost process is the current menu bar for the database.
• One or more windows: Each process can have more than one window open simultaneously. On the other hand, some processes have no windows at all.
• One active (frontmost) window: Even though a process can have several windows open simultaneously, each process has only one active window. To have more than one active window, you must start more than one process.

Notes:

• Processes do not include menu bars by default which means that the standard Edit menu shortcuts (in particular, cut/copy/paste) are not availalbe in process windows. When you call dialog boxes or 4D editors (form editor, query editor, Request, etc.) from a process, if you want for the user to be able to benefit from keyboard shortcuts like copy/paste, you need to make sure that the equivalent of an Edit menu is installed in the process.
• Preemptive processes and processes that are executed on the server (stored procedures) must not contain elements of the interface.

Data elements refer to the data used by the database. The data elements are:

• Current selection per table: Each process has a separate current selection. One table can have a different current selection in different processes.
• Current record per table: Each table can have a different current record in each process.

Note: This description of the data elements is valid if your processes are global in scope. By default, all processes are global. See the “Global and Local Processes” section below.

The language elements of a process are the elements related to programming in 4D.

• Variables: Every process has its own process variables. See Variables for more information. Process variables are recognized only within the domain of their native process.
• Default table: Each process has its own default table. However, note that the DEFAULT TABLE command is only a typing convention for programming.
• Input and Output forms: Default input and output forms can be set procedurally for each table in each process.
• Process sets: Each process has its own process sets. LockedSet is a process set. Process sets are cleared as soon as the process method ends.
• On Error Call per process: Each process has its own error-handling method.
• Debugger window: Each process can have its own Debugger window.

User processes are processes that you create to perform certain tasks. They share processing time with the kernel processes. As an example, Web connection processes are user processes.

The 4D application also creates processes for its own needs. The following processes are created and managed by 4D:

• Main process: The main process manages the display windows of the user interface.
• Design process: The Design process manages the windows and editors of the Design environment. There is no Design process in a compiled database that does not contain interpreted code.
• Web Server process: The Web Server process runs when the database is published on the Web. See the Web server configuration and connection management section for more information.
• Cache Manager process: The Cache Manager process manages disk I/ O for the database. This process is created as soon as 4D or 4D Server are run.
• Indexing process: The Indexing process manages the indexing of fields in a database as a separate process. This process is created when an index for a field is built or deleted.
• On Event Manager process: This process is created when an event-handling method is installed by the ON EVENT CALL command. It executes the event method installed by ON EVENT CALL whenever there is an event. The event method is the process method for this process. This process executes continuously, even if no method is executing. Event handling also occurs in the Design environment.

Starting with 4D v15 R5 64 bits, 4D allows you to create preemptive user processes in compiled mode. In previous versions, only cooperative user processes were available.

When run in preemptive mode, a process is dedicated to a CPU. Process management is then delegated to the system, which can allocate each CPU separately on a multi-core machine. When run in cooperative mode, all processes are managed by the parent application thread and share the same CPU, even on a multi-core machine.

As a result, in preemptive mode, overall performance of the application is improved, especially on multi-core machines, since multiple processes (threads) can truly run simultaneously. However, actual gains depend on the operations being executed. In return, since each thread is independent from the others in preemptive mode, and not managed directly by the application, there are specific constraints applied to methods that you want to be compliant with preemptive use. Additionally, preemptive execution is only available in certain specific contexts.

Management of preemptive processes is covered in the Preemptive 4D processes section. 

Processes can be either global or local in scope. By default, all processes are global.

Global processes can perform any operation, including accessing and manipulating data. In most cases, you will want to use global processes.

Local processes should be used only for operations that do not access data. For example, you can use a local process to run an event-handling method or to control interface elements such as floating windows.

You specify that a process is local in scope through its name. The name of local process must start with a dollar sign ($).

Warning: If you attempt to access data from a local process, you access it though the main process, risking conflicts with operations performed within that process.

4D Server: Using local processes on the Client side for operations that do not require data access reserves more processing time for server-intensive tasks.

A record is locked when another process has successfully loaded the record for modification. A locked record can be loaded by another process, but cannot be modified. The record is unlocked only in the process in which the record is being modified. A table must be in read/write mode for a record to be loaded unlocked. For more information, refer to the Record Locking section.