Sin duda, los futuros o promesas son la funcionalidad más importante que incorporamos en el futuro Xailer 7 e incluso al propio lenguaje de programación Harbour. Los futuros o promesas son ampliamente conocidos por programadores de otros lenguajes más modernos y para aquellos que aún no los conozcáis, creo que la mejor introducción para ellos es decir que son la simplificación completa de la programación multi-hilo.
Según la Wikipedia, un valor futuro (también llamado un futuro o una promesa) es un remplazo para un resultado que todavía no está disponible, generalmente debido a que su cómputo todavía no ha terminado, o su transferencia por la red no se ha completado. Puede parecer una definición un poco críptica, pero indica claramente su funcionalidad aunque no hace mención a cómo funcionan ni en que se basan. La funcionalidad de los futuros o promesas está totalmente ligada a la programación multi-hilo. La programación multi-hilo puede llegar a ser tremendamente compleja debido a la facilidad existente de cometer errores de programación que colapsen nuestras aplicaciones o las hagan actuar de forma inesperada.
Un futuro o promesa está estrechamente ligado con el concepto de asíncrono. Es decir, un código que sabemos cuándo lo ejecutamos, pero que no sabemos cuando retornará con un resultado. Pensemos un una función estándar; ésta siempre devuelve un resultado cuando se termina de ejecutar el código que tiene en su interior. Si dicha función tiene que acceder a Internet o realizar un trabajo pesado, nuestra aplicación se quedará completamente paralizada hasta que dicho código termine. Para evitar este problema, en clásica programación multi-hilo crearíamos un proceso asíncrono a través de un hilo:
TThread():Run( bCode )Donde bCode, es por ejemplo, un bloque de código que se ejecutará cuando se inicie el hilo. Independientemente del tiempo de proceso que necesite dicho código, el retorno desde la ejecución de esa línea será inmediato. Por lo tanto, será responsabilidad suya el crear mecanismos para saber cuando ese código ha terminado y si lo ha hecho correctamente o no. El asunto se complica cuando desde dicho código que se ejecuta en un segundo hilo queremos acceder a zonas de memoria que no han sido creadas en ese mismo hilo o incluso se pretende acceder a la pantalla en el más amplio sentido. La primera regla de oro a tener en cuenta es que desde un hilo secundario nunca se debe acceder a la pantalla y esto es así para cualquier entorno de desarrollo. No es una limitación de Xailer, Harbour o Windows. Aunque le parezca que funciona, olvídese, es un auténtico espejismo, su aplicación terminará con un GPF esporádico más pronto que tarde. La segunda regla de oro es evitar acceder a áreas de memoria creadas por el hilo principal u otros hilos y si se hace, establecer los mecanismos necesarios para que todos los hilos involucrados puedan acceder a esas mismas zonas de memoria de forma ordenada y sin bloquearse. En definitiva, demasiadas complicaciones que impiden que la programación multi-hilo sea ampliamente utilizada.
Los futuros o promesas nos simplifican tremendamente todos estos inconvenientes. Y en Xailer 7 apostamos totalmente por ellos.
Continuará …
Nota: Comentarios abiertos. Si está interesado no dude en hacérnoslo saber. Muchas gracias.