{"id":1013,"date":"2012-08-30T00:48:03","date_gmt":"2012-08-29T22:48:03","guid":{"rendered":"http:\/\/blog.rastersoft.com\/?p=1013"},"modified":"2012-08-30T00:48:03","modified_gmt":"2012-08-29T22:48:03","slug":"funciones-asincronas-en-vala","status":"publish","type":"post","link":"https:\/\/blog.rastersoft.com\/?p=1013","title":{"rendered":"Funciones as\u00edncronas en Vala"},"content":{"rendered":"

Actualizado.<\/strong> Acabo de modificar un poco el c\u00f3digo de Cronopete<\/a> para que haga uso de las funciones as\u00edncronas de Vala<\/a>. El motivo es eliminar, en la medida de lo posible, el uso de threads.<\/p>\n

Las funciones as\u00edncronas de Vala son una ayuda muy interesante a la hora de realizar tareas que requieren mucho tiempo, a la vez que se quiere evitar que la interfaz se bloquee. La soluci\u00f3n m\u00e1s inmediata en estos casos consiste en crear un thread<\/em> y realizar en \u00e9l todo el proceso, pero en ocasiones es una soluci\u00f3n muy compleja, pues se necesita intercambiar datos entre \u00e9ste y el thread<\/em> principal, o sincronizar ambos. La soluci\u00f3n est\u00e1 en las funciones as\u00edncronas. Estas son funciones que pueden interrumpirse y reanudarse a voluntad en cualquier punto, lo que permite realizar una forma de multitarea cooperativa<\/a> de manera sencilla.<\/p>\n

Imaginemos que definimos una funci\u00f3n o m\u00e9todo as\u00edncronos as\u00ed:<\/p>\n

\n
public async int AsyncFnc(int p1, int p2, out int p3, out String p4) {\n    \/\/ c\u00f3digo de la funci\u00f3n as\u00edncrona (tambi\u00e9n puede ser un m\u00e9todo de una clase)\n    [...]\n}<\/pre>\n<\/div>\n
Para llamar a esta funci\u00f3n, lo haremos de esta manera:<\/p>\n
\n
AsyncFnc.begin(p1, p2, callback_finalizacion);<\/pre>\n<\/div>\n
Vemos que s\u00f3lo incluimos los par\u00e1metros de entrada, pero no los de salida. Por otro lado, tampoco recogemos el valor devuelto. Por \u00faltimo, tenemos un misterioso callback_finalizacion<\/em>. Este par\u00e1metro es opcional, y s\u00f3lo hay que a\u00f1adirlo cuando se desea ejecutar alg\u00fan c\u00f3digo cuando la funci\u00f3n as\u00edncrona finalice. Es en dicha funci\u00f3n donde recogeremos los valores de salida y cualquier excepci\u00f3n que se produjese durante la ejecuci\u00f3n de la funci\u00f3n as\u00edncrona. Dicho callback es de tipo GLib.AsyncReadyCallback<\/em>, y su formato es el siguiente:<\/p>\n
\n
public delegate void AsyncReadyCallback (Object? source_object, AsyncResult res)<\/pre>\n<\/div>\n
Sin embargo, Vala nos ofrece algunas ventajas, como son las funciones an\u00f3nimas y los closures<\/a>, que nos dan como ventaja el poder acceder desde el callback a variables externas a \u00e9stas. As\u00ed pues, utilizando una funci\u00f3n an\u00f3nima podemos llamar a nuestra funci\u00f3n as\u00edncrona as\u00ed:<\/p>\n
\n
AsyncFnc.begin(p1, p2, (obj,res) => {\n\n    int retval;\n    retval=AsyncFnc.end(res, out p3, out p4);\n\n    \/\/ resto del c\u00f3digo del callback\n    [...]\n});<\/pre>\n<\/div>\n
De esta manera, cuando la funci\u00f3n as\u00edncrona llegue al final y retorne, se ejecutar\u00e1 el c\u00f3digo de callback<\/em> contenido en el closure<\/em>. Vemos tambi\u00e9n que llamamos a AsyncFnc.end<\/em>; esta es, precisamente, la manera que tenemos de obtener el valor devuelto por la funci\u00f3n as\u00edncrona, as\u00ed como los par\u00e1metros de salida. Tambi\u00e9n es esta llamada la que debemos rodear con un try\/catch()<\/em> si queremos capturar cualquier excepci\u00f3n lanzada desde dentro de la funci\u00f3n as\u00edncrona.<\/p>\n
As\u00ed pues, ya sabemos llamar a una funci\u00f3n as\u00edncrona, y sabemos como recibir sus resultados. \u00bfPero como hacemos para que ceda el control y devolv\u00e9rselo? No olvidemos que NO se tratan de varios threads paralelos, sino de un \u00fanico hilo de ejecuci\u00f3n.<\/p>\n
La respuesta est\u00e1 en yield<\/em> y .callback()<\/em>. La primera es una llamada que, al realizarla dentro de una funci\u00f3n as\u00edncrona, devuelve el control a la funci\u00f3n llamante. La segunda es un m\u00e9todo de la funci\u00f3n as\u00edncrona (igual que .begin<\/em> y .end<\/em>; podemos comparar una funci\u00f3n as\u00edncrona con un objeto que ofrece esos tres m\u00e9todos p\u00fablicos) que lo que hace es continuar la ejecuci\u00f3n de dicha funci\u00f3n justo despu\u00e9s del \u00faltimo yield<\/em> ejecutado. Un detalle interesante es que las llamadas a yield<\/em> se pueden situar absolutamente en cualquier parte de una funci\u00f3n as\u00edncrona, incluso dentro de un bucle, lo que nos permite, de una manera sencilla, devolver el control en cada iteraci\u00f3n para que se vayan ejecutando otras partes del c\u00f3digo, y recuperarlo para la siguiente iteraci\u00f3n.<\/p>\n
Ahora que ya tenemos la imagen completa podemos ver como se ejecuta el c\u00f3digo: cuando una funci\u00f3n normal llama a una funci\u00f3n as\u00edncrona, le cede el control y \u00e9sta comienza a ejecutarse hasta alcanzar el primer yield<\/em>. En ese punto la llamada retorna a la funci\u00f3n normal, y sigue ejecut\u00e1ndose el c\u00f3digo situado a continuaci\u00f3n de la llamada. Cuando, en alg\u00fan punto posterior, se llame al .callback()<\/em> de la funci\u00f3n as\u00edncrona, el control pasar\u00e1 al c\u00f3digo situado justo despu\u00e9s de dicho primer yield<\/em>, y seguir\u00e1 ejecut\u00e1ndose hasta que encuentre otro yield<\/em>, momento en que el control de la ejecuci\u00f3n pasar\u00e1 al c\u00f3digo situado justo despu\u00e9s de la llamada a .callback()<\/em>. Este juego de ping-pong<\/em> continuar\u00e1 hasta que la funci\u00f3n as\u00edncrona llegue al final y retorne. En ese momento se ejecutar\u00e1 el c\u00f3digo del callback y continuar\u00e1 la ejecuci\u00f3n despu\u00e9s de la \u00faltima llamada a .callback()<\/em>.<\/p>\n
Un ejemplo gr\u00e1fico<\/h2>\n
Para entender mejor este proceso, ve\u00e1moslo en forma gr\u00e1fica. Por cuestiones de claridad lo dividiremos en dos im\u00e1genes: en la primera veremos el flujo desde que se inicia la funci\u00f3n as\u00edncrona hasta que est\u00e1 a punto de acabar, y en la segunda desde que se ejecuta el return<\/em> al final.<\/p>\n
\"\"<\/a><\/p>\n
En la imagen anterior vemos la primera parte del ciclo de vida de una funci\u00f3n as\u00edncrona. Cada funci\u00f3n est\u00e1 representada por un rect\u00e1ngulo, y dentro de ella, el flujo de ejecuci\u00f3n natural es de arriba a abajo.<\/p>\n
Desde el Main Loop<\/em> de la aplicaci\u00f3n se llama a un callback <\/em>(por ejemplo, porque el usuario ha pulsado un bot\u00f3n en la interfaz gr\u00e1fica), llamado\u00a0Function<\/em> en este ejemplo, y en \u00e9ste se llama a nuestra funci\u00f3n as\u00edncrona (llamada AsyncFnc<\/em> en el ejemplo), que comienza a ejecutarse. En el momento en el que se alcanza el primer yield<\/em>, el control vuelve al callback<\/em> que la lanz\u00f3, que sigue su ejecuci\u00f3n hasta que, en un punto, \u00e9ste llama a AsyncFnc.callback()<\/em>. En ese momento el flujo de ejecuci\u00f3n vuelve a la funci\u00f3n as\u00edncrona, que contin\u00faa justo en la instrucci\u00f3n que sigue al primer yield<\/em>. Un poco despu\u00e9s se llega a un segundo yield<\/em>, que devuelve el control al callback<\/em> original.<\/p>\n
Cuando el callback<\/em> termina, se devuelve el control al Main Loop<\/em>, como siempre. Pero la funci\u00f3n as\u00edncrona a\u00fan no ha terminado. Vemos entonces que en dos puntos determinados se llama a AsyncFnc.callback()<\/em>. Estas llamadas no son autom\u00e1ticas, sino que tuvieron que ser preprogramadas (por ejemplo con un temporizador, o con una llamada a Idle.add(AsyncFnc.callback)<\/em> para que se ejecuten en un momento en que no hay eventos por despachar). Cada vez que se llama a dicha funci\u00f3n, la ejecuci\u00f3n de la funci\u00f3n as\u00edncrona contin\u00faa justo despu\u00e9s del \u00faltimo yield<\/em>, hasta que encuentra otro, o bien hasta que finaliza la funci\u00f3n.<\/p>\n
\"\"<\/a><\/p>\n
En el siguiente esquema, las flechas en rojo muestran el flujo de ejecuci\u00f3n cuando la funci\u00f3n as\u00edncrona llega al final: en ese momento se ejecuta el callback<\/em> registrado cuando se lanz\u00f3 la funci\u00f3n (si es que existe, claro; si no se defini\u00f3, se retorna directamente), y cuando se termina \u00e9ste, se retorna al punto de llamada.<\/p>\n
Llamar a una funci\u00f3n as\u00edncrona desde otra funci\u00f3n as\u00edncrona<\/h2>\n
A la hora de llamar a una funci\u00f3n as\u00edncrona desde otra funci\u00f3n as\u00edncrona, la primera idea que nos puede venir a la cabeza es hacer<\/p>\n
\n
\/\/ ATENCION, ESTE CODIGO NO FUNCIONARA CORRECTAMENTE\n\nasync void AsyncFnc1() {\n    int retval;\n\n    [...]\n   \u00a0AsyncFnc2( (ob,res) => {\n        retval=AsyncFnc2.end();\n\u00a0       AsyncFnc1.callback();\n    });\n    yield;\n    [...]\n}<\/pre>\n<\/div>\n
Aparentemente, este c\u00f3digo lanzar\u00eda\u00a0AsyncFnc2<\/em> y suspender\u00eda la ejecuci\u00f3n de AsyncFnc1, pero de manera que, al terminarse la ejecuci\u00f3n de AsyncFnc2<\/em>, continuar\u00eda la ejecuci\u00f3n de AsyncFnc1<\/em>.<\/p>\n
Por desgracia, ese c\u00f3digo es probable que no funcione correctamente, como m\u00ednimo en un caso concreto: si, por la raz\u00f3n que sea, la funci\u00f3n AsyncFnc2<\/em> finaliza sin llamar a yield<\/em> al menos una vez, se llamar\u00e1 antes a AsyncFnc1.callback()<\/em> que al yield<\/em>, por lo que el c\u00f3digo fallar\u00e1. Una soluci\u00f3n a este problema ser\u00eda utilizar Idle.add(AsyncFnc1.callback)<\/em> en su lugar, pero s\u00f3lo funcionar\u00e1 si tenemos un Main Loop<\/em> en nuestro programa, pues ser\u00e1 \u00e9ste quien llame al callback despu\u00e9s de que la funci\u00f3n as\u00edncrona retorne tras ejecutar el yield<\/em>.<\/p>\n
Afortunadamente, los dise\u00f1adores de Vala eran conscientes de que es muy com\u00fan llamar a una funci\u00f3n as\u00edncrona desde otra, por lo que simplificaron notablemente este caso concreto. As\u00ed, para llamar a AsyncFnc2<\/em> desde AsyncFnc1<\/em>, de manera que \u00e9sta \u00faltima contin\u00fae su ejecuci\u00f3n cuando acabe la otra, s\u00f3lo hay que hacer<\/p>\n
\n
async void AsyncFnc1() {\n    int retval;\n\n    [...]\n    retval=yield AsyncFnc2();\n    [...]\n}<\/pre>\n<\/div>\n
Otra ventaja es que, en este caso, no necesitamos llamar a AsyncFnc2.end()<\/em> para obtener los resultados, porque se hace directamente.<\/p>\n
El flujo de ejecuci\u00f3n ser\u00eda as\u00ed:<\/p>\n
\"\"<\/a><\/p>\n
Vemos que desde el Main Loop<\/em> llamamos a nuestra primera funci\u00f3n as\u00edncrona, AsyncFnc1<\/em>, y despu\u00e9s de un trozo de c\u00f3digo llamamos, mediante yield<\/em>, a nuestra segunda funci\u00f3n as\u00edncrona, AsyncFnc2<\/em>. En \u00e9sta ejecutamos algo de c\u00f3digo y llegamos a un yield<\/em>. Sin embargo, \u00e9ste no retorna a AsyncFnc1, sino a la llamada anterior. Esto es as\u00ed porque AsyncFnc1<\/em> lo que quiere es dormir hasta que AsyncFnc2<\/em> termine.<\/p>\n
Tambi\u00e9n vemos que para reanudar la ejecuci\u00f3n es preciso llamar a AsyncFnc2.callback()<\/em>. Esto debe tenerse muy en cuenta: en este instante es incorrecto llamar a AsyncFnc1.callback()<\/em>. Por eso es fundamental que cada funci\u00f3n as\u00edncrona se encargue de programar su llamada para recuperar el control, y no delegarlo a funciones externas, pues es muy f\u00e1cil cometer errores.<\/p>\n
Cuando AsyncFnc2<\/em> llega al final, se cede el control al c\u00f3digo de AsyncFnc1<\/em>, que sigue ejecut\u00e1ndose, y al terminar, se llamar\u00eda a la funci\u00f3n de\u00a0callback de finalizaci\u00f3n (si la hubiera), y seguir\u00eda la ejecuci\u00f3n justo a continuaci\u00f3n de la llamada a AsyncFnc2.callback()<\/em> (que, en este caso, simplemente seguir\u00eda con la ejecuci\u00f3n del Main Loop<\/em>).<\/p>\n
Casos de uso de funciones as\u00edncronas<\/h2>\n
El primer caso de uso de las funciones as\u00edncronas es para llamar a otras funciones as\u00edncronas. Esto, que puede parecer una perogrullada, toma sentido en cuanto descubrimos las funciones as\u00edncronas de Gio<\/em><\/a>. Un ejemplo es el de File.copy_async<\/a>: este m\u00e9todo de la clase File<\/a> copia un fichero de manera as\u00edncrona. De no existir, tendr\u00edamos que crear un hilo y ejecutar en \u00e9l la funci\u00f3n s\u00edncrona de copia, porque de no hacerlo as\u00ed, si el fichero fuese muy grande la interfaz gr\u00e1fica de nuestro programa se quedar\u00eda congelada durante la operaci\u00f3n.<\/p>\n
Hay dos maneras de llamar a estas funciones as\u00edncronas: la primera es la cl\u00e1sica, incluyendo un callback<\/em> (bien como puntero a funci\u00f3n, bien como funci\u00f3n an\u00f3nima o closure<\/em>) que se llame cuando termine la operaci\u00f3n; la segunda, m\u00e1s c\u00f3moda en seg\u00fan que casos, es llamarla mediante yield<\/em> desde una funci\u00f3n as\u00edncrona de Vala. En este segundo caso hay que saltarse el par\u00e1metro del callback.<\/p>\n
El segundo caso de uso es para llamar a servicios externos mediante DBus<\/em><\/a>. De esta manera podemos aprovechar el tiempo entre el env\u00edo de la petici\u00f3n y la llegada de la respuesta. Para ello, basta con a\u00f1adir async<\/em> en la definici\u00f3n de la interfaz DBus<\/em>. Un ejemplo de como definir la interfaz DBus<\/em> para formatear un disco, mediante el demonio UDisks<\/em><\/a>:<\/p>\n
\n
[DBus (name = \"org.freedesktop.UDisks.Device\")]\ninterface Device_if : GLib.Object {\n\tpublic abstract async void FilesystemCreate(string type, string[] options) throws IOError;\n}<\/pre>\n<\/div>\n
Por desgracia, en este caso concreto no podemos aprovechar la funcionalidad de la llamada mediante yield<\/em>, debido a que existe un timeout<\/em> en las llamadas a m\u00e9todos DBus<\/em> de, aproximadamente, 25 segundos, y se necesita m\u00e1s tiempo para formatear algunos soportes. Se supone que se puede ajustar este timeout<\/em> mediante un modificador de Vala, pero despu\u00e9s de consultar en la lista de correo y de buscar en internet, no he conseguido que funcione. Si alguna alma caritativa nos puede iluminar…<\/p>\n
El siguiente caso de uso es cuando se quiere realizar una tarea larga y que consuma CPU, pero no se quieren usar threads o lanzar un proceso paralelo, sino ejecutarlo en los momentos en los que el proceso actual est\u00e9 inactivo (en el caso de una aplicaci\u00f3n gr\u00e1fica, cuando no hay eventos que procesar en la cola). La soluci\u00f3n consiste en crear una funci\u00f3n as\u00edncrona que realice la tarea, insertando llamadas a yield<\/em> de manera regular. Para que la funci\u00f3n se despierte cuando la cola est\u00e1 vac\u00eda, usamos Idle.add()<\/em> para llamar al m\u00e9todo .callback()<\/em> de nuestra funci\u00f3n as\u00edncrona, as\u00ed:<\/p>\n
\n
public async void AsyncFnc() {\n\n    \/\/ Inicializaci\u00f3n de variables y dem\u00e1s\n    [...]\n\n    \/\/ Comienza la tarea\n    while(cond==true) {\n\n        \/\/ Realizamos una iteraci\u00f3n de la tarea\n        [....]\n\n       \u00a0\/\/ Avisamos al Main Loop que queremos que nos despierte\n        \/\/ cuando no haya eventos pendientes\n        Idle.add(AsyncFnc.callback);\n\n        \/\/ Y devolvemos el control al b\u00facle principal o Main Loop\n        yield;\n    }\n\n    \/\/ La tarea ha finalizado\n    \/\/ Limpiamos todo\n    [...]\n}<\/pre>\n<\/div>\n
Por supuesto, podemos utilizar tambi\u00e9n un temporizador en lugar de Idle<\/em>, o cualquier otro sistema que decidamos.<\/p>\n
Un detalle interesante que se puede ver en este ejemplo es que la llamada a yield<\/em> puede ir dentro de un bucle while<\/em> o for<\/em> sin ning\u00fan problema.<\/p>\n
Por \u00faltimo, tambi\u00e9n son \u00fatiles para sincronizar threads<\/em>. El truco en este caso est\u00e1 en almacenar un puntero al m\u00e9todo de callback de la funci\u00f3n as\u00edncrona que queremos sincronizar, lanzar el thread<\/em>, y al final de \u00e9ste, a\u00f1adir dicho callback<\/em> a la cola de mensajes. El esquema es \u00e9ste:<\/p>\n
\n
async void AsyncFunc() {\n\n    \/\/ Aqu\u00ed almacenamos el m\u00e9todo .callback()<\/em> de nuestra funci\u00f3n as\u00edncrona\n    SourceFunc callback = AsyncFunc.callback;\n\n    \/\/ Creamos la funci\u00f3n para el thread. La hacemos an\u00f3nima (closure) para que tenga acceso a la\n    \/\/ variable local callback<\/em>.\n    ThreadFunc<void*> run = () => {\n        \/\/ C\u00f3digo del thread. Aqu\u00ed hacemos las operaciones deseadas\n        [...]\n\n        \/\/ Aqu\u00ed ya hemos terminado las operaciones, as\u00ed que\n        \/\/ a\u00f1adimos el m\u00e9todo .callback()<\/em> a la cola para que se llame inmediatamente\n        Idle.add((owned) callback);\n        return null;\n    };\n\n    \/\/ Lanzamos el thread\n    Thread.create<void*>(run, false);\n\n    \/\/ Y esperamos a que se llame a nuestra funci\u00f3n callback\n    \/\/ que ser\u00e1 cuando termine el thread\n    yield;\n}<\/pre>\n<\/div>\n
En la documentaci\u00f3n oficial se encuentran tres ejemplos de funciones as\u00edncronas<\/a>, muy \u00fatiles para entender a\u00fan mejor esta \u00fatil caracter\u00edstica de Vala. En concreto aparece un ejemplo del m\u00e9todo de sincronizaci\u00f3n de threads<\/em>, donde se puede ver mucho mejor la sintaxis concreta.<\/p>\n","protected":false},"excerpt":{"rendered":"
Actualizado. Acabo de modificar un poco el c\u00f3digo de Cronopete para que haga uso de las funciones as\u00edncronas de Vala. El motivo es eliminar, en la medida de lo posible, el uso de threads. Las funciones as\u00edncronas de Vala son una ayuda muy interesante a la hora de realizar tareas que requieren mucho tiempo, a … Seguir leyendo Funciones as\u00edncronas en Vala<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,7],"tags":[],"class_list":["post-1013","post","type-post","status-publish","format-standard","hentry","category-programacion","category-tutoriales"],"_links":{"self":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/1013","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1013"}],"version-history":[{"count":0,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=\/wp\/v2\/posts\/1013\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1013"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1013"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.rastersoft.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1013"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}