About workers

A Worker process is a simple and powerful way to exchange information between processes.  This feature is based upon an asynchronous messaging system that allows processes and forms to be called and asked to execute methods with parameters in their own context.

Note: A project method can also be executed with parameters in the context of any form using the CALL FORM command.

A worker can be "hired" by any process (using the CALL WORKER command) to execute project methods with parameters in their own context, thus allowing access to shared information.

This functionality addresses the following needs regarding 4D interprocess communication:

• Since they are supported by both cooperative and preemptive processes, they are the perfect solution for interprocess communication in preemptive processes (interprocess variables are not allowed in preemptive processes).
• They provide a simple alternative to semaphores, which can be cumbersome to set and complex to use (see About semaphores).

Note: Although they have been designed mainly for interprocess communication in the context of preemptive processes (64-bit versions only), CALL WORKER and CALL FORM are available in 32-bit versions and can be used with cooperative processes. 

A worker is used to ask a process to execute project methods. A worker consists of:

• a unique name(*), also used to name its associated process
• an associated process, that may or may not exist at a given moment
• a message box
• a startup method (optional)

(*) Warning: Worker names are case sensitive ("myWorker" and "MyWorker" can exist simultaneously).

You ask a worker to execute a project method by calling the CALL WORKER command. The worker and its message box are created at first use; its associated process is also automatically launched at first use. If the worker process dies thereafter, the message box remains open and any new message in the box will start a new worker process.

The following animation illustrates this sequence:

Unlike the New process command, a worker process remains alive after the execution of the process method ends. This means that all method executions for the same worker will be run in the same process, which maintains all process state information (process variables, current record and current selection, etc.). Consequently, methods executed successively will access and thus share the same information, allowing communication between processes. The worker's message box handles successive calls asynchronously.

CALL WORKER encapsulates both the method name and command arguments in a message that is posted in the worker's message box. The worker process is then started, if it does not already exist, and asked to execute the message. This means that CALL WORKER will usually return before the method is actually executed (processing is asynchronous). For this reason, CALL WORKER does not return any value. If you need a worker to send information back to the process which called it (callback), you need to use CALL WORKER again to pass the information needed to the caller. Of course, in this case, the caller itself must be a worker.

It is not possible to use CALL WORKER to execute a method in a process created by the New process command. Only worker processes have a message box and can thus be called by CALL WORKER. Note that a process created by New process can call a worker, but cannot be called back.

Worker processes can be created on 4D Server through stored procedures: for example, you can use the Execute on server command to execute a method that calls the CALL WORKER command.

A worker process is closed by a call to the KILL WORKER command, which empties the worker's message box and asks the associated process to stop processing messages and to terminate its current execution as soon as the current task is finished.

The startup method of a worker is the method used to create the worker (at first use). If CALL WORKER is called with an empty method parameter, then the startup method is automatically reused as method to execute.

The main process created by 4D when opening a database for user and application modes is a worker process and can be called using CALL WORKER. Note that the name of the main process may vary depending on the 4D localization language, but it always has the process number 1; as a result, it's more convenient to designate it by process number instead of process name when calling CALL WORKER.

All worker processes, except the main process, have the process type Worker process (5) returned by the PROCESS PROPERTIES command.

New icons identify worker processes in the Runtime Explorer and the 4D Server administration window:

Process type	Icon
Preemptive worker process
Cooperative worker process

Note: Other existing process icons have been updated in 4D v15 R5.

The following graphic shows a communication sequence between two workers and a form. Information is exchanged by means of strings:

1. Worker_1 calls Worker_2 and passes "Hello!" as parameter.
2. Worker_2 gets the message and reads it. It calls Worker_1 back and passes "Hello!" as parameter.
3. Worker_2 then calls the MyForm form and passes "I am working" as parameter. It begins a time-consuming operation and its status becomes 'busy'.
4. Worker_1 calls Worker_2 twice but, thanks to the asynchronous messaging system, messages are simply queued. They are processed once Worker_2 is available - after Worker_2 has called MyForm.