Sobre workers

Un proceso Worker es una forma sencilla y poderosa de intercambiar información entre procesos. Esta funcionalidad se basa en un sistema de mensajería asíncrono que permite a los procesos y formularios ser llamados y se les pide ejecutar métodos con parámetros en su propio contexto.

Nota: un método de proyecto también puede ejecutarse con los parámetros en el contexto de todo formulario utilizando el comando CALL FORM.

Un worker puede ser "contratado" por cualquier proceso (utilizando el comando CALL WORKER) para ejecutar los métodos de proyecto con parámetros en su propio contexto, permitiendo así el acceso a información compartida.

Esta funcionalidad responde a las siguientes necesidades en materia de comunicación entre procesos en 4D:

• Ya que son compatibles con ambos procesos cooperativos y apropiativos, son la solución perfecta para la comunicación entre procesos en los procesos apropiativos (las variables interproceso no están permitidas en los procesos apropiativos).
• Ofrecen una alternativa sencilla a los semáforos, que puede ser engorrosos de definir y difíciles de usar (ver Sobre los semáforos).

Nota: aunque se han diseñado principalmente para la comunicación entre procesos en el contexto de los procesos apropiativos (sólo en versiones 64 bits), CALL WORKER y CALL FORM están disponibles en versiones 32 bits y se pueden utilizar con los procesos cooperativos.

Un worker se utiliza para pedir a un proceso ejecutar los métodos proyecto. Un worker está hecho de:

• un nombre único (*), también se utiliza para nombrar su proceso asociado
• un proceso asociado, que puede o no puede existir en un momento dado
• un buzón de mensajes
• un método de inicio (opcional)

(*) Advertencia: los nombres de los workers son sensibles a las mayúsculas y minúsculas ("myWorker" y "MyWorker" pueden existir simultáneamente).

Se le pide a un worker ejecutar un método proyecto mediante una llamada al comando CALL WORKER. El worker y su buzón de mensajes se crean en el primer uso; su proceso asociado también se ejecuta automáticamente en el primer uso. Si el proceso worker muere luego, el buzón de mensajes permanece abierto y cualquier nuevo mensaje en el buzón iniciará un nuevo proceso worker .

La siguiente animación ilustra esta secuencia:

A diferencia del comando New process, un proceso worker permanece vivo después del final de la ejecución del método proceso. Esto significa que todas las ejecuciones del procedimiento para el mismo worker se llevarán a cabo en el mismo proceso, que mantiene toda la información de estado del proceso (variables de proceso, registro actual y selección actual ...). En consecuencia, los métodos ejecutados sucesivamente tendrán acceso y de este modo compartirán la misma información, lo que permite las comunicaciones entre procesos. El buzón de mensajes del worker maneja las llamadas sucesivas de forma asíncrona.

CALL WORKER encapsula el nombre del método y los argumentos del comando en un mensaje que se publica en buzón de mensajes del worker. El proceso worker se inicia a continuación si no existe y se pide ejecutar el mensaje. Esto significa que CALL WORKER generalmente volverá antes de que el método se ejecute (el procesamiento es asíncrono). Por esta razón, CALL WORKER no devuelve ningún valor. Si necesita un worker para enviar información al proceso que lo llamó (retrollamada), es necesario utilizar CALL WORKER nuevamente para pasar al llamante la información necesaria. Por supuesto, en este caso, el llamante debe ser un worker.

No es posible utilizar CALL WORKER para ejecutar un método en un proceso creado por el comando New process. Sólo los procesos worker tienen un buzón de mensajes y, por tanto, pueden ser llamados por CALL WORKER. Tenga en cuenta que un proceso creado por New process puede llamar a un worker, pero no puede llamarse de nuevo.

Los procesos worker se pueden crear en 4D Server a través de procedimientos almacenados: por ejemplo, puede utilizar el comando [#cmd id="373"/] para ejecutar un método que llama al comando [#cmd id="1389"/].

Un proceso worker se cierra mediante una llamada al comando KILL WORKER, que vacía el buzón de mensajes del worker, le pide al proceso asociado detener el procesamiento de mensajes y terminar su ejecución actual después del final de la tarea actual.

El método de inicio de un worker es el método utilizado para crear el worker (como primer uso). Si CALL WORKER se llama con un parámetro metodo vacío, luego se reutiliza automáticamente el método de inicio como método a ejecutar.

El proceso principal creado por 4D cuando se abre una base para los modos aplicación y usuario es un proceso worker y puede llamarse con CALL WORKER. Tenga en cuenta que el nombre del proceso principal puede variar en función del lenguaje de localización 4D, pero tiene siempre número de proceso 1; en consecuencia, es más conveniente para designarlo por el número de proceso en lugar del nombre del proceso al llamar CALL WORKER.

Todos los procesos workers, excepto el proceso principal, tienen el tipo Worker process (5) que devuelve el comando PROCESS PROPERTIES.

Nuevos iconos identifican los procesos workers en el Explorador de ejecución y en la ventana de administración de 4D Server:

Tipo de proceso	Icono
Proceso worker apropiativo
Proceso worker cooperativo

Nota: otros iconos de proceso existentes se han actualizado en 4D v15 R5.

El siguiente gráfico muestra una secuencia de comunicación entre dos workers  y un formulario. La información intercambiado son sólo cadenas:

1. Worker_1 llama a Worker_2 y pasa "Hello!" como parámetro.
2. Worker_2 recibe y lee el mensaje. Llama de nuevo a Worker_1 y pasa "Hello!" como parámetro.
3. Worker_2 a continuación, llama al formulario MyForm y pasa "I work" como parámetro. Se inicia una operación que consume tiempo y su estado se convierte en "ocupado".
4. Worker_1 llama a Worker_2 dos veces, pero, gracias al sistema de mensajería asíncrona, el mensaje simplemente se pone en cola. Se procesan una vez Worker_2 esté disponible, después Worker_2 ha llamado a MyForm.