4D Summit 2016: Laurent Esnault presents workers and UI in preemptive mode

Our own VP of Engineering, Laurent Esnault, explains exchanging information between multiple processes AND between processes and forms during his Break Out Session: Preemptive Multi-threading at 4D Summit 2016. Thanks to preemptive multi-threading, you can have more parallel processes, and thus add more and more users, for either desktop or web applications.

If you missed Laurent’s session at 4D Summit 2016, watch this 15-min video and enjoy some personal training by the master of preemptive multi-threading!

Prerequisites

To take advantage of preemptive multi-threading, you’ll need to use:

• 64-bit only
• compiled mode
• preemptive-ready command only
• No interprocess variables
• No user interface

But don’t be afraid! We’ve got some powerful and easy solutions that we’ll present in detail with illustrative examples.

How to share info between processes

If you don’t have inter-process variables in preemptive mode, how do you share information between processes? This is why we’re introducing a new concept: “workers”. But what exactly is a worker?

Glad you asked! It’s a message box associated with a process specifically dedicated to execute its messages. Using the CALL WORKER command, you can post a message from one process to another (to send it information, or ask it to do something). The syntax of this command is pretty similar to the New process command, e.g. you can pass any parameter and/or project method.

Let’s use a small animation to better understand how it works:

In this example, we want to pass information from the application process to the myWorker process. The application process is running and the myWorker process is paused.

• In the application process, the CALL WORKER command is called to pass some parameters to myWorker, and we want myWorker to execute the myMethod project method.
• It creates a message that is posted asynchronously to a message box dedicated to the myWorker process. The flag is up, so the worker automatically awakens and picks up the message, retrieves the contents (the parameters) and executes myMethod.
• When the myWorker process has finished executing myMethod, it doesn’t die. It’s just paused, waiting for another message to execute. This is the main difference from the New process command, which creates a process, executes a method with some parameters, then dies.

So when does a worker die? Basically, it will die when you close the application or if you call the KILL WORKER command. It doesn’t abruptly kill the process, it just sends a message to the worker asking it to commit suicide.

Demonstration: Workers

Take a look at the example database used for the demonstration with corresponding explanations in Vanessa’s post about workers.

How to access the user Interface from preemptive processes

Earlier, we said you can’t access the user interface from a preemptive process. Obviously, we needed to provide a solution for that. Hence, the introduction of the CALL FORM command. This command is similar to the CALL WORKER command. This time, however, it’s not a message box associated to a process, it is a message box associated a window.

CALL FORM allows you to send a message to a window to ask the form running inside it to execute a method with some parameters.

Let’s use a small animation again to demonstrate the concept:

 

In this example, from within a process (which could be preemptive) or a worker, we want to do something in a running form in the same process or another one.

• We call the CALL FORM command and pass the window reference number (i.e. the long int value returned by the Open form window command) in the input parameter, as the project method we want to execute (myMethod) with some parameters.
• It creates a message which is posted asynchronously to a message box associated with the window.
• The process handling the window automatically detects that it has a message. It picks up the message and executes the myMethod method and its parameters.
• Then the process continues to handle the window “as usual” (handling events like key down, mouse down, etc.).

As you can see, this is pretty similar to the previous example about workers.

Demonstration: messaging between forms

Check out the example database used for the demonstration with corresponding explanations in Vanessa’s post about messaging between forms.