Envío de mensajes

Cuando se emplea el portal como mecanismo para enviar un mensaje de un shuttle a otro, la invocación del portal causa la ejecución (de modo asíncrono) de un manejador en el contexto del servidor.

Para permitir este uso de los portales se ha incluido junto con el manejador (contador de programa e información para obtención de pila) un identificador de shuttle que identifica el shuttle en que deberá ejecutar dicho manejador. El núcleo salvará el estado de dicho shuttle e instalará el contexto necesario para la ejecución asíncrona del manejador. Si un portal no tiene instalado este identificador de shuttle no será factible su uso para envío asíncrono de mensajes.

El algoritmo de envío de mensajes en este caso es sencillo:

1. Se realiza la llamada al sistema sys_portal_send.
2. Se localiza el portal, si es remoto se enviará una excepción (mediante un upcall) de tal modo que se reenvíe la petición al nodo en que se encuentra el portal. Si es local se continúa.
3. Se localiza el shuttle destino mediante la función needs:
   • Si éste es remoto se eleva una excepción (mediante un upcall) para que se localice el shuttle destino y se reenvíe la petición al nodo en que éste se encuentre. El kernel entrega las palabras que constituyen el mensaje como parámetro de la rutina llamada mediante el upcall. Se realiza una migración (implícita) del portal al nodo destino.
   • Si es local se continúa. En este punto el portal comparte nodo con el shuttle que lo maneja, esto facilita el resto de la operación.
4. Se bloquea al shuttle destino y se salva su estado. Esto se realiza tanto si el shuttle ejecutaba en modo kernel (estaba a mitad de una llamada al sistema) como si ejecutaba normalmente código de la aplicación. Este estado se salva en la pila de kernel del shuttle destino.
5. Se instala un registro de activación para upcall (la rutina que realiza upcalls) en la pila de kernel del shuttle destino y se fija su estado de tal modo que cuando éste ejecute realice inmediatamente un upcall. El kernel copia las palabras que constituyen el mensaje de tal modo que la rutina upcall (en el kernel del shuttle destino) pueda transferirlas hasta el manejador del portal (empleando sus parámetros).

   Los parámetros de upcall situados en el registro de activación creado para ella están dispuestos de tal modo que upcall realizará un upcall al manejador del portal tan pronto como el shuttle destino ejecute.

   La dirección de retorno del registro de activación preparado para upcall está dispuesta de tal modo que se salte a una rutina que restaurará el estado del shuttle destino a la situación en que este se encontrase antes de quedar bloqueado (sea ésta la ejecución dentro del kernel o fuera del mismo).

6. Se modifican las propiedades del shuttle destino de acuerdo con la máscara de propiedades presente en el portal.
7. Se desbloquea al shuttle destino.
8.   Se retorna de la llamada al sistema sys_portal_send. El resto del envío procede en el contexto del shuttle destino, de tal modo que el origen puede continuar su tarea.
9. Un trampolín instalado en el punto anterior, que ejecuta cuando el manejador retorna devolverá el control al kernel. En este punto se restaura el estado (y las propiedades alteradas por la invocación del portal) salvado anteriormente. Así pues este punto corresponde en realidad al retorno del upcall que entrega el mensaje.

El shuttle que invoca el portal recupera el control en el punto 8 y puede proseguir su ejecución. La ejecución del manejador aguardará hasta el momento en que el shuttle destino disponga de un quantum para ejecutar.

Si el mensaje precisase de respuesta el remitente puede incluir un identificador de portal como parte del mensaje y bloquearse justo tras el envío. El destinatario empleará dicho identificar para enviar una respuesta al cliente; como efecto lateral de la recepción éste quedará desbloqueado.

Por último, conviene recordar que todas las operaciones efectuadas sobre shuttles se efectúan empleando los servicios del servidor de shuttles. Así por ejemplo, para bloquear al shuttle destino o cederle el resto del quantum de procesador de que disponemos empleamos las rutinas shtl_switch y shtl_setProp, suministradas por el servidor de shuttles.