4D Summit 2016: Laurent Esnault presenta lavoratori e UI in modalità preventiva

Il nostro vicepresidente dell’ingegneria, Laurent Esnault, spiega come scambiare informazioni tra più processi e tra processi e forme durante la sua Break Out Session: Preemptive Multi-threading al 4D Summit 2016. Grazie al preemptive multi-threading, è possibile avere più processi paralleli e quindi aggiungere sempre più utenti, sia per le applicazioni desktop che per quelle web.

Se vi siete persi la sessione di Laurent al 4D Summit 2016, guardate questo video di 15 minuti e godetevi la formazione personale del maestro del multi-threading preemptive!

Prerequisiti

Per sfruttare il multi-threading preemptive, è necessario utilizzare:

• solo 64 bit
• modalità compilata
• solo il comando preemptive-ready
• Nessuna variabile interprocesso
• Nessuna interfaccia utente

Ma non abbiate paura! Abbiamo alcune soluzioni semplici e potenti che presenteremo in dettaglio con esempi illustrativi.

Come condividere le informazioni tra i processi

Se non avete variabili interprocesso in modalità preemptive, come fate a condividere le informazioni tra i processi? Per questo motivo introduciamo un nuovo concetto: “lavoratori”. Ma cos’è esattamente un worker?

Mi fa piacere che l’abbiate chiesto! Si tratta di una finestra di messaggio associata a un processo specificamente dedicato all’esecuzione dei suoi messaggi. Utilizzando il comando CALL WORKER è possibile inviare un messaggio da un processo a un altro (per inviargli informazioni o chiedergli di fare qualcosa). La sintassi di questo comando è abbastanza simile a quella del comando New process ad esempio, si può passare qualsiasi parametro e/o metodo di progetto.

Utilizziamo una piccola animazione per capire meglio come funziona:

In questo esempio, vogliamo passare informazioni dal processo di applicazione al processo myWorker. Il processo applicativo è in esecuzione e il processo myWorker è in pausa.

• Nel processo di applicazione, il comando CALL WORKER viene chiamato per passare alcuni parametri a myWorker e vogliamo che myWorker esegua il metodo di progetto myMethod.
• Crea un messaggio che viene inviato in modo asincrono a una casella di messaggi dedicata al processo myWorker. Il flag è alzato, quindi il worker si sveglia automaticamente e raccoglie il messaggio, recupera il contenuto (i parametri) ed esegue myMethod.
• Quando il processo myWorker ha finito di eseguire myMethod, non muore. È solo in pausa, in attesa di un altro messaggio da eseguire. Questa è la differenza principale rispetto al comando New process che crea un processo, esegue un metodo con alcuni parametri e poi muore.

Quando muore un worker? Fondamentalmente, muore quando si chiude l’applicazione o se si chiama il comando KILL WORKER o se si richiama il comando. Il comando non uccide bruscamente il processo, ma invia semplicemente un messaggio al worker, chiedendogli di suicidarsi.

Dimostrazione: Lavoratori

Date un’occhiata al database di esempio utilizzato per la dimostrazione, con le relative spiegazioni nel post di Vanessa sui worker.

Come accedere all’interfaccia utente da processi preemptive

Prima abbiamo detto che non è possibile accedere all’interfaccia utente da un processo preemptive. Ovviamente, era necessario fornire una soluzione a questo problema. Da qui l’introduzione del comando CALL FORM . Questo comando è simile al comando CALL WORKER . Questa volta, però, non si tratta di una casella di messaggio associata a un processo, ma di una casella di messaggio associata a una finestra.

CALL FORM consente di inviare un messaggio a una finestra per chiedere al modulo in esecuzione al suo interno di eseguire un metodo con alcuni parametri.

Utilizziamo di nuovo una piccola animazione per dimostrare il concetto:

In questo esempio, dall’interno di un processo (che potrebbe essere preemptive) o di un worker, vogliamo fare qualcosa in un modulo in esecuzione nello stesso processo o in un altro.

• Chiamiamo il CALL FORM e passiamo il numero di riferimento della finestra( cioè il valore long int restituito dal comando) nel parametro di input, come parametro di ingresso. Open form window ) nel parametro di input, come il metodo del progetto che vogliamo eseguire(myMethod) con alcuni parametri.
• Si crea un messaggio che viene inviato in modo asincrono a una casella di messaggi associata alla finestra.
• Il processo che gestisce la finestra rileva automaticamente di avere un messaggio. Raccoglie il messaggio ed esegue il metodo myMethod e i suoi parametri.
• Poi il processo continua a gestire la finestra “come al solito” (gestendo eventi come la pressione dei tasti, la pressione del mouse e così via).

Come si può notare, si tratta di un’operazione abbastanza simile all’esempio precedente sui lavoratori.

Dimostrazione: messaggistica tra moduli

Per vedere il database di esempio utilizzato per la dimostrazione, con le relative spiegazioni, consultate il post di Vanessa sulla messaggistica tra i moduli.