THINGS, ¿qué son esas "cosas"? - parte 1

Jochen Merz
Alemania
Artículo aparecido en la revista QL Today volumen 4 número 1

Traducción:
Afx
Mayo de 2009

Sé que debería haber escrito este artículo hace algún tiempo, pero yo no estaba seguro de qué escribir y cómo empezar.

Decidí que debería empezar con algún tipo de explicación general acerca de los "Things"1, contar lo que podrías hacer con ellos (probablemente, ya los habrás usado durante bastante tiempo sin saberlo) y dar una explicación de cómo usarlos y cómo crearlos. Por supuesto, esto no va a caber en una sola entrega y como no queremos llenar este artículo con un largo listado en ensamblador solamente, yo dividiré el tema en varias partes. Tómalo como un tutorial, y esta es la primera entrega de tres.

Para asegurarme de que no se confunden demasiado los términos2, pondré la palabra "Things" en mayúsculas, cuando me refiera a los Things de SMSQ.

El nombre Thing fué elegido porque un Thing puede ser virtualmente cualquier cosa. Puede ser un controlador de dispositivo, un área de datos, puede ser un menú, puede ser una extensión del sistema, puede ser un programa ...

La primera ventaja de los Thing es que tienen un nombre único. Tu puedes identificar a un Thing por su nombre, y localizarlo en la memoria del sistema. Un Thing puede estar localizado en cualquier sitio en la memoria de tu ordenador, y la única forma de encontrarlo es por su nombre (de forma similar a como nos referimos a un fichero específico en el sistema de archivos por medio de su nombre).

Si un job (tarea) quiere usar un Thing (hay diferentes maneras de usar los Thing, dependiendo de lo que son realmente, pero veremos eso más adelante), en primer lugar, el job tiene que tratar de averiguar si el Thing existe en tu sistema -de otro modo no podría usarlo-. De forma análoga a un archivo, si tratamos de abrir un archivo de disco, debemos buscar previamente si existe o no ese archivo.

Si el Thing existe y se le permite al job usarlo (puede haber limitaciones que dependen del Thing, algunos Thing sólo permite ser usado por un usuario a la vez, otros pueden ser usados por más de un usuario3) entonces el job es marcado como un usuario de ese Thing particular, el job "sabe" que el Thing existe y obtiene su dirección de memoria. Es incluso posible que se produzca un timeout cuando se intenta usar un Thing (es posible por ejemplo cuando se intenta abrir un fichero y esa tarea falla), útil para los Thing que pueden ser usados sólo por un usuario al mismo tiempo, por lo que el job puede intentarlo durante un tiempo predefinido o abortar el intento.

La dirección del Thing es lo que obtienes, y eso es todo lo que necesitas porque ésta es la principal idea: una especie de "sistema indexado" para partes del sistema software de tu ordenador, junto con un registro de usuarios. Suena simple ¿no es así? y en realidad lo es.

Un job es un usuario del Thing hasta que lo libera (similar al "cierre"). En la medida en que un job es un usuario de un Thing, su "vida" depende de la presencia del ese Thing. Como SMSQ es, al igual que QDOS, un sistema con auto-limpieza, eso significa que si se remueve algo del sistema, todos los ítems relacionados con él son también de alguna manera cerrados o liberados. Si tu remueves un trabajo en SMSQ/QDOS, entonces todos los canales que son propiedad de este job son automáticamente cerrados por el sistema, toda la memoria propiedad del job es retornada a la lista de memoria libre, todos los jobs de los que éste es propietario son liberados y así de forma recursiva hasta que todos los recursos que son propiedad o son usados por este job son liberados.

Los Things van un paso más allá. Cuando un job se convierte en un usuario de un Thing, parece lógico que quiera hacer algo con él y confía en su presencia. Si el Thing es liberado de la memoria, entonces naturalmente todos los jobs que están registrados como usuarios de ese Thing son liberados también por el sistema, de otro modo ¿cómo podría continuar la ejecución de un job si el Thing necesario ya no está disponible? Esto podría conducir a resultados inesperados y seguramente nosotros preferiríamos tener un sistema estable. Pude sonar un poco tosco el remover jobs de esta manera, pero piénsalo ¿qué otra cosa se puede hacer?

DIFERENTES THINGS...

Como ya he mencionado ... es posible tener diferentes tipos de Things. Teóricamente es posible que cada trozo o sección de la memoria pudiera ser un "Thing". Esto probablemente sería "excesivo", pero sin embargo sería posible. No es necesario que todas las localizaciones de memoria sean reconocibles por su nombre, pero si lo piensas bien, podrías encontrar que es útil el que largas partes de la memoria, que contienen diferentes partes del sistema operativo y controladores de dispositivos sean reconocidos por su nombre. Podrías personalizar tu sistema mientras esté en funcionamiento, agregar controladores, liberar controladores, actualizar controladores.

En el pasado añadir otro controlador de disco-RAM mientras otro controlador de disco-RAM estaba siendo usado no conducía a un sistema limpio. El antiguo controlador de disco-RAM permanecía en el sistema y tú te encontrabas con dos entradas "RAM" en la lista de dispositivos de QPAC2, la primera no se eliminaba. Todavía podías acceder a él, esto podría ser un poco complicado, pero es posible. ¿Y qué ocurre con los ficheros que estaban abiertos en la primera unidad de disco-RAM? Pues que permanecerán abiertos hasta que tú lo cirraras. Si abres de nuevo el mismo nombre de archivo otra vez se abrirá a un diferente disco-RAM .... ooooop, ambiguo, ¿no?

Si el controlador de disco-RAM fuera un Thing, entonces cuando el nuevo disco-RAM fuera cargado el viejo disco-RAM sería removido del sistema, la totalidad de la memoria reservada para él sería liberada y el job con los canales abiertos a ese disco-RAM serían liberados. ¿Qué otra cosa se puede hacer? No hay medias tintas en este proceso.

Los Things también pueden ser muy útiles en las extensiones del sistema. La extensión "Menu" es un ejemplo muy bueno. Si tu reemplazas la extensión "Menu" por una versión más reciente, la antigua extensión se descarga completamente de la RAM y se sustituye por la nueva versión. Pruébalo: inicia QD (un editor de texto que usa la extensión "Menu"), intenta cargar un archivo, pero cuando el cuadro de selección del archivo aparece (éste cuadro de diálogo no forma parte de QD sino es que forma parte de la extensión "Menu" en ese momento) regresa al BASIC y vuelve a cargar la extensión "Menu" una vez más (empleando LRESPR MENU_rext). En primer lugar, la antigua copia de la extensión "Menu" es removida (y por tanto, QD también será removido, -recuerda, todos los procesos usuarios de un Thing son liberados cuando se libera el Thing) y posteriormente la nueva extensión "Menu" es instalada en el sistema.

QD, editor de textos de Jochen Merz que hace uso de Things

Thing Menu, un Thing creado por Jochen Merz que actúa como cuadro de diálogo para buscar ficheros, es muy popular y es usado por muchas aplicaciones

QD (y otros programas) solamente usan Things en el momento en el que realmente los necesitan, esto significa que puedes cargar una nueva extensión Menu sin necesidad de remover los jobs que lo están usando en ese momento. Sería posible (y puede que un poco más rápido) para un job registrarse a sí mismo como usuario de la extensión Menu (obteniendo la dirección de la extensión) y luego seguir siendo usuario de esa extensión y llamarla cada vez que se necesite, esto ahorrará algunas llamadas y también funcionaría (recordemos que la dirección no cambia: si reemplazamos la extensión Menu, lo que llevaría a un cambio de esta dirección, no provocaría ningún daño, porque en ese momento los usuarios de la extensión serían liberados).

Espero que por ahora no estés muy confundido, una vez más piensa en el sistema de los Things como un sistema de identificación y registro.

No hay ningún límite sobre lo que pueden ser los Things. Parece lógico que si podemos tener extensiones Thing, nosotros podemos tener Things ejecutables también (al igual que con los archivos, puedes observar la analogía en todo momento). Es posible tener muchos canales de entrada al mismo tiempo, así ¿por qué no tener muchos usuarios que utilizan el mismo código de programa el cual sólo existe una vez en memoria?.

Este es el concepto de los Things ejecutables. El código de programa, es el mismo todo el tiempo sin importar si cero, uno o cualquier número del mismo job lo usa, sólo necesita estar en memoria una sola vez. Todos los programas QPAC2 son Things ejecutables, y tú puedes ejecutar tantos como tú quieras mientras dispongas de memoria.

Ahora, seguramente estarás definitivamente de acuerdo que los jobs o usuarios de los Things deben desalojarse si éste se elimina de la memoria, ¿cómo se pude ejecutar un programa si su código necesario se ha ido? Como podrás ver, el concepto no suena demasiado drástico ¿no?

El tercer tipo general de Thing es el Thing del tipo "datos". Una vez más, es responsabilidad del programador definir la estructura de datos que se almacenan aquí, cómo se organizan y como deben ser usados. No me canso de repetirlo: el sistema de Things es una herramienta para ayudar al job (a la tarea) a encontrar y a registrar un conjunto de información o de datos para luego usarlos.

Creo que eso es suficiente por el momento. En la próxima parte vamos a echar un vistazo a los Things en tu sistema (siempre que hayas cargado QPAC2) y una de las varias formas que existen para crear un Thing tú mismo.

Continúa en el siguiente artículo

1.- Thing significa "cosa"
2.- Para no confundir el termino "cosa" (thing) con el nombre "Thing" en inglés.
3.- "Usuario" se refiere a un programa que lo usa, no a un operador humano.

Artículo original: http://www.dilwyn.me.uk/docs/articles/thingtxt.zip
Sinclair QL Recursos en Castellano Alojado en / Hosted at:
Sinclair QL Recursos en Castellano
Sinclair QL Spanish Resources