Clonando Elementary OS en Gnome Shell

Pues eso es lo que he estado haciendo fundamentalmente este mes, porque poquito a poquito, slingshot_app_launcher para Gnome Shell ya funciona exactamente igual que la versión original de Elementary OS: no sólo permite escoger entre mostrar por categorías o todo junto, sino también buscar aplicaciones tecleando su nombre. Además, he corregido algunos bugs en el tamaño de la ventana (también funciona en monitores pequeños), y lo he hecho mucho más compatible con los CSS de Gnome Shell, de manera que si cambias el estilo (o tema), el menú se ajustará a éste.

Por otro lado, aproveché también para subir la última versión de Transmission para WebTV, donde únicamente actualicé la versión de transmission a la última, la 2.77.

Cronopete, WebTV y Gnome Shell

Desde mi última entrada hasta hoy he hecho unas cuantas cositas, pero no las comenté por aquí por falta de tiempo. Y dado que al final no se ha acabado el mundo, vamos a retomar las buenas costumbres.

En primer lugar, lancé una nueva versión de Cronopete, la 3.6.0, que justo hoy actualicé a la 3.8.1. El principal cambio ha sido un lifting de la interfaz de restauración de ficheros, además de incluir paquetes .deb con las versiones GTK2 y GTK3.

Por otro lado, lancé una nueva versión de Transmission para WebTV, la 5.0. En ella, además de incluir la última versión de Transmission, he recompilado todas las bibliotecas desde cero para tener las más recientes y he sustituido el viejo periscope por mi versión modificada de submarine. Ahora, por fin, vuelven a funcionar los subtítulos. Por desgracia, el autor aún no ha mezclado mis cambios con su rama, así que le he escrito y estoy esperando su respuesta.

Por último, he vuelto a Gnome Shell desde Elementary. El motivo es que necesito tener iconos en el escritorio, y de la forma que trabaja Gala (el gestor de ventanas de Elementary) no es nada cómodo hacerlo: cada vez que un escritorio virtual se queda sin ventanas abiertas, se mueve al anterior automáticamente. Aunque en Gnome Shell ocurre algo parecido (cambia a modo Actividades u Overview) tiene la ventaja de que se pueden añadir extensiones de manera relativamente sencilla. Pero a la vez echaba de menos algunas características de Elementary, así que me lié la manta a la cabeza y escribí dos:

  • Slingshot: se trata de un clon para Gnome Shell del menú lanzador de aplicaciones de Elementary.
  • AvoidOverview: elimina, precisamente, el molesto cambio de modo cuando se cierran todas las ventanas de un escritorio, pero permitiendo que se siga accediendo mediante los hotspots, el botón de Actividades, o la tecla windows.

Reconozco que la elección de JavaScript para crear Gnome Shell me resultaba curiosa al principio, pero ahora que he escrito estas dos extensiones puedo entender los motivos: gracias a la técnica de Monkey Patch, es posible cambiar el funcionamiento de cualquier parte del escritorio sin necesidad de modificar los fuentes originales, porque JavaScript permite modificar en caliente los métodos de un objeto. Esto no es necesario cuando simplemente se quiere hacer un módulo sencillo que incluya un menú, un icono, un botón, etc. pues para ello existe una API muy bien definida. Este es el caso de Slingshot, que no necesita ninguna de estas técnicas.

Sin embargo, para cambiar la forma en que responde el escritorio en funciones muy internas, como hace AvoidOverview, no queda más remedio que usarlas. Y aunque reconozco la potencia y versatilidad que ofrecen, tengo que decir que no me gustan demasiado, porque no puedo evitar ver el resultado como sucio. La apariencia no es la de un módulo que se enchufa en un punto específico mediante una interfaz bien definida, sino la de un parche aplicado con cinta aislante, cortando pistas del circuito impreso, y sujetando todo con una brida.

Pese a todo, en conjunto creo que el resultado ha sido acertado, porque de limitarnos exclusivamente a una API para módulos, probablemente no se podría jamás incorporar un cambio en algo tan profundo como esto. No olvidemos la postura de Gnome de reducir al mínimo las opciones de configuración del escritorio: no creo que aceptasen ni cambiar en la rama oficial el funcionamiento del modo Overview, ni incluir la opción de configurarlo.

Esto le da un nuevo sentido a un comentario que leí sobre Gala, el gestor de ventanas de Elementary OS, que también está basado en la tecnología de Gnome 3 (y que, por desgracia, no recuerdo donde la leí). Venía a decir que lo importante no es tanto el escritorio en sí, sino la tecnología que hay debajo, con mutter y demás, porque con ella se pueden hacer nuevos escritorios con facilidad, como es el caso de Gala o Cinnamon. Y así es: no hace falta que en la rama principal se añadan todas las opciones imaginables, porque es perfectamente posible modificar el funcionamiento interno con bastante facilidad, y simplemente añadiendo unas cuantas extensiones se puede cambiar de arriba a abajo la forma de trabajar del sistema.

Para aquellos que quieran saber cual ha sido mi elección, comentar que, además de AvoidOverview y Slingshot, tengo las siguientes extensiones:

  • Coverflow Alt-tab: cambia el funcionamiento de las teclas Alt+Tab por un cambiador al estilo cover-flow, además de mostrar sólo las ventanas del escritorio actual.
  • Hide Dash: elimina el dash (barra de aplicaciones situada a la izquierda). Lo tengo porque prefiero tener plank en la parte baja de la pantalla.
  • No top-left hot corner: desactiva el hotspot de arriba a la izquierda, que permite entrar en el modo Overview. Necesario porque, si no, es muy fácil que se active cuando se intenta lanzar una aplicación desde Slingshot.
  • Remove Accesibility: elimina el icono de configuración de la accesibilidad. Cabe señalar que es la extensión más descargada para Gnome Shell… por algo será 😉

A mayores también tengo System-Monitor y Workspace navigator, pero esas ya son por gusto propio. Con estas extensiones, y activando Nautilus para que gestione los iconos del escritorio, he podido darle la vuelta por completo a la forma de trabajar de Gnome Shell, ajustándolo exactamente a como yo lo quiero.

Subtitulando

Estos días estoy liado buscando alternativas a periscope para bajar subtítulos de manera automática. El motivo es que no es un proyecto que esté siendo mantenido de manera razonable.

De casualidad encontré subliminal, un programa similar pero con más fuentes de subtítulos, y decidí echarle un ojo. La verdad es que funciona muy bien, pero tiene el inconveniente de que, al igual que periscope, está escrito en python, lo que significa que hay que meter una máquina virtual completa en mi WebTV.

Pero de casualidad encontré submarine, otro programa similar pero escrito en Vala, lo que significa que puedo compilarlo en un ejecutable y ahorrarme todo el interprete de python. Por desgracia, este sólo soporta búsquedas en OpenSubtitles.org y en Podnapisi.net. Sin embargo, su modelo interno es tan sumamente sencillo que he conseguido añadir soporte para SubDB (el cual ya está subido a mi repositorio GIT personal y solicitado un commit al oficial).

Extraoficialmente también he conseguido implementar soporte para BierDopje, pero ese código todavía no lo puedo subir porque sigo a la espera de que me concedan una clave específica para la API (en estos momentos estoy usando prestada la de subliminal, pero cada aplicación tiene que usar la suya propia).

El uso de este portal tiene su complicación, en buena medida porque mientras que SubDB utiliza un hash del archivo para buscar subtítulos, BierDopje pide el nombre de la serie, la temporada y el capítulo. En subliminal se utiliza la impresionante biblioteca guessit, que, a partir del nombre del fichero, y mediante una serie de heurísticos, extrae toda la información posible sobre un fichero. Obviamente dicha biblioteca está escrita en python, así que tuve que hacer una versión de andar por casa en Vala. El concepto básico es el mismo (de hecho, fusilé todo lo que pude), pero, al estar hecha en una noche, no es tan precisa. Obviamente acepto parches para mejorarla.

Para jugar bien

En la entrada anterior explicaba el problema que supone jugar cuando se utiliza un gestor de ventanas por composición. Este problema se describe con más detalle en los artículos The Cost Of Running CompizMutter Can Cause A Gaming/OpenGL Performance Hit Too. El principal motivo es que los programas no pintan directamente sobre la pantalla, sino sobre un buffer oculto, y es el gestor de ventanas el que, de manera periódica, copia dicho buffer a la zona visible.

La solución que proponía era aumentar la prioridad del gestor de ventanas y del servidor X, pero dado que es una operación algo liosa para alguien que no tenga unos mínimos conocimientos, decidí hacer un pequeño programa que lo automatizase. Ese programa se llama GAMEd. La esencia es muy sencilla: tenemos una lista de ejecutables almacenada en /etc/gamed.conf. Cada vez que se lanza el gestor de ventanas y el entorno de escritorio, se llama mediante DBus al demonio GAMEd (y si no estaba lanzado, el propio DBus lo lanza como root). Este demonio recorre la lista de procesos actuales, y cambia su prioridad a cada uno que coincida con alguno de la lista. De esta manera es posible asignar prioridades altas desde el espacio de usuario sin abrir un agujero de seguridad, porque sólo se cambiarán aquellos programas autorizados.

El sistema está diseñado para ser completamente transparente: por defecto asigna prioridad -15, pero se puede utilizar el comando renice_gamed para escoger cualquier otra (podría llegarse hasta -20, pero en el código de un programa similar, AutoNICEd, recomienda no hacerlo, así que GAMEd simplemente redondea a -15 si se pone una prioridad mayor). Dicha prioridad se almacena y se utiliza todas las veces que se llame al demonio, hasta que el usuario la vuelva a cambiar si quiere.

Por otro lado se añade un pequeño script en el arranque del escritorio, que llama al demonio. Esto hace que cada vez que se arranque el ordenador y se entre en la sesión, se ajustará de nuevo automáticamente la prioridad de las X y del gestor de ventanas.

Yo lo he probado en Gala y en Compiz y se nota la diferencia, pero no he podido probarlo en Gnome-Shell por ciertos problemas de compatibilidad de paquetes entre éste y Elementary OS.

Así pues, si jugáis regularmente en vuestro equipo Linux y notáis pérdida de rendimiento y de FPS en vuestros juegos, probad a instalar GAMEd y contadme qué tal os ha ido.

Juego elemental

Llevo una temporadita probando Elementary OS, y tengo que decir que me encanta. Es un concepto de escritorio y sistema operativo que, salvo un par de detalles, encaja como un guante en lo que busco. Tanto es así que estoy asegurándome de que Cronopete esté perfectamente integrado en él.

Por otro lado, hace poco descubrí Limbo, un juego con una ambientación sencillamente impresionante.

Sin embargo, me encontré con que la mezcla de ambos no funcionaba muy bien: había «saltos» entre fotogramas, se conseguían muy pocos FPS y había un retardo brutal (casi un segundo) entre la pulsación de una tecla y que el personaje ejecutase la acción correspondiente. Al principio lo achaqué a Wine (es un juego para windows), pero buscando información encontré que al resto de gente le funcionaba perfectamente.

Lo primero que hice fue cambiar del driver privativo de AMD/ATI (FGLRX) al libre (Radeon), y los saltos desaparecieron, pero los bajos FPS y el retardo seguían allí.

Recordé que había una crítica general contra los gestores de ventanas por composición como Compiz, Mutter y KWin, porque tienen que renderizar el contenido de cada ventana cada vez que la aplicación lo cambia. Ante esto, probé a arrancar una sesión de gnome-fallback-session, y allí funcionaba perfectamente, lo que confirmó que el problema estaba en Gala (el gestor de ventanas de Elementary).

Sin embargo, pensando, llegué a la conclusión de que perfectamente podía deberse al retardo en la conmutación entre tareas, así que decidí probar a asignarle máxima prioridad (-19) tanto al servidor X como a Gala. Para ello usé el comando renice (como root, porque si no, no permite asignar valores negativos, correspondientes a la máxima prioridad). Con eso el problema se resolvió, y el juego funcionó con una suavidad total, igual que si no estuviese utilizando un gestor de ventanas por composición.

PPAs

Tras arduos intentos, por fin he conseguido crear un repositorio PPA para Cronopete. Gracias a él, los usuarios de Debian, Ubuntu y Elementary OS tendrán mucho más fácil instalarlo. También gracias a esto he conseguido pulir algunos problemillas en los scripts de CMake, para que funcione al 100% la instalación en directorios no estándar.

En cronopete en sí casi no hay cambios, salvo haber añadido soporte de D-Bus activation, para que si no está lanzado, y el usuario hace click en el icono de configuración o de restauración de archivos, se lance automáticamente.

Lo que no he conseguido aún es que, tras instalar el paquete, el sistema pida al usuario reiniciar (y que así se lance Cronopete en el siguiente arranque).

¡A disfrutarla!

Lavado de cara

Después de unos cuantos años con la misma apariencia, y varios comentarios de otra gente, me decidí a cambiar un poco el diseño de mi web. No es que sea un cambio radical, pero al menos está más limpio.

Por otro lado acabo de lanzar la versión 3.4.0 de Cronopete (sí, he decidido usar números de sub-versión impares para las versiones de desarrollo), con varias novedades internas. La principal es que ahora utilizo CMake para compilarlo, por lo que será más fácil que terceros hagan paquetes DEB o RPM. Por otro lado, he simplificado los mensajes y retocado los gráficos, además de portarlo a appindicator. Todo esto con el objetivo de que sea incorporado a Elementary OS en un futuro cercano (o lo que es lo mismo: en la versión siguiente a Luna).

Que la disfrutéis con salud.

Funciones asíncronas en Vala

Actualizado. Acabo de modificar un poco el código de Cronopete para que haga uso de las funciones asíncronas de Vala. El motivo es eliminar, en la medida de lo posible, el uso de threads.

Las funciones asíncronas 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ón más inmediata en estos casos consiste en crear un thread y realizar en él todo el proceso, pero en ocasiones es una solución muy compleja, pues se necesita intercambiar datos entre éste y el thread principal, o sincronizar ambos. La solución está en las funciones asíncronas. Estas son funciones que pueden interrumpirse y reanudarse a voluntad en cualquier punto, lo que permite realizar una forma de multitarea cooperativa de manera sencilla.

Imaginemos que definimos una función o método asíncronos así:

public async int AsyncFnc(int p1, int p2, out int p3, out String p4) {
    // código de la función asíncrona (también puede ser un método de una clase)
    [...]
}

Para llamar a esta función, lo haremos de esta manera:

AsyncFnc.begin(p1, p2, callback_finalizacion);

Vemos que sólo incluimos los parámetros de entrada, pero no los de salida. Por otro lado, tampoco recogemos el valor devuelto. Por último, tenemos un misterioso callback_finalizacion. Este parámetro es opcional, y sólo hay que añadirlo cuando se desea ejecutar algún código cuando la función asíncrona finalice. Es en dicha función donde recogeremos los valores de salida y cualquier excepción que se produjese durante la ejecución de la función asíncrona. Dicho callback es de tipo GLib.AsyncReadyCallback, y su formato es el siguiente:

public delegate void AsyncReadyCallback (Object? source_object, AsyncResult res)

Sin embargo, Vala nos ofrece algunas ventajas, como son las funciones anónimas y los closures, que nos dan como ventaja el poder acceder desde el callback a variables externas a éstas. Así pues, utilizando una función anónima podemos llamar a nuestra función asíncrona así:

AsyncFnc.begin(p1, p2, (obj,res) => {

    int retval;
    retval=AsyncFnc.end(res, out p3, out p4);

    // resto del código del callback
    [...]
});

De esta manera, cuando la función asíncrona llegue al final y retorne, se ejecutará el código de callback contenido en el closure. Vemos también que llamamos a AsyncFnc.end; esta es, precisamente, la manera que tenemos de obtener el valor devuelto por la función asíncrona, así como los parámetros de salida. También es esta llamada la que debemos rodear con un try/catch() si queremos capturar cualquier excepción lanzada desde dentro de la función asíncrona.

Así pues, ya sabemos llamar a una función asíncrona, y sabemos como recibir sus resultados. ¿Pero como hacemos para que ceda el control y devolvérselo? No olvidemos que NO se tratan de varios threads paralelos, sino de un único hilo de ejecución.

La respuesta está en yield y .callback(). La primera es una llamada que, al realizarla dentro de una función asíncrona, devuelve el control a la función llamante. La segunda es un método de la función asíncrona (igual que .begin y .end; podemos comparar una función asíncrona con un objeto que ofrece esos tres métodos públicos) que lo que hace es continuar la ejecución de dicha función justo después del último yield ejecutado. Un detalle interesante es que las llamadas a yield se pueden situar absolutamente en cualquier parte de una función asíncrona, incluso dentro de un bucle, lo que nos permite, de una manera sencilla, devolver el control en cada iteración para que se vayan ejecutando otras partes del código, y recuperarlo para la siguiente iteración.

Ahora que ya tenemos la imagen completa podemos ver como se ejecuta el código: cuando una función normal llama a una función asíncrona, le cede el control y ésta comienza a ejecutarse hasta alcanzar el primer yield. En ese punto la llamada retorna a la función normal, y sigue ejecutándose el código situado a continuación de la llamada. Cuando, en algún punto posterior, se llame al .callback() de la función asíncrona, el control pasará al código situado justo después de dicho primer yield, y seguirá ejecutándose hasta que encuentre otro yield, momento en que el control de la ejecución pasará al código situado justo después de la llamada a .callback(). Este juego de ping-pong continuará hasta que la función asíncrona llegue al final y retorne. En ese momento se ejecutará el código del callback y continuará la ejecución después de la última llamada a .callback().

Un ejemplo gráfico

Para entender mejor este proceso, veámoslo en forma gráfica. Por cuestiones de claridad lo dividiremos en dos imágenes: en la primera veremos el flujo desde que se inicia la función asíncrona hasta que está a punto de acabar, y en la segunda desde que se ejecuta el return al final.

En la imagen anterior vemos la primera parte del ciclo de vida de una función asíncrona. Cada función está representada por un rectángulo, y dentro de ella, el flujo de ejecución natural es de arriba a abajo.

Desde el Main Loop de la aplicación se llama a un callback (por ejemplo, porque el usuario ha pulsado un botón en la interfaz gráfica), llamado Function en este ejemplo, y en éste se llama a nuestra función asíncrona (llamada AsyncFnc en el ejemplo), que comienza a ejecutarse. En el momento en el que se alcanza el primer yield, el control vuelve al callback que la lanzó, que sigue su ejecución hasta que, en un punto, éste llama a AsyncFnc.callback(). En ese momento el flujo de ejecución vuelve a la función asíncrona, que continúa justo en la instrucción que sigue al primer yield. Un poco después se llega a un segundo yield, que devuelve el control al callback original.

Cuando el callback termina, se devuelve el control al Main Loop, como siempre. Pero la función asíncrona aún no ha terminado. Vemos entonces que en dos puntos determinados se llama a AsyncFnc.callback(). Estas llamadas no son automáticas, sino que tuvieron que ser preprogramadas (por ejemplo con un temporizador, o con una llamada a Idle.add(AsyncFnc.callback) para que se ejecuten en un momento en que no hay eventos por despachar). Cada vez que se llama a dicha función, la ejecución de la función asíncrona continúa justo después del último yield, hasta que encuentra otro, o bien hasta que finaliza la función.

En el siguiente esquema, las flechas en rojo muestran el flujo de ejecución cuando la función asíncrona llega al final: en ese momento se ejecuta el callback registrado cuando se lanzó la función (si es que existe, claro; si no se definió, se retorna directamente), y cuando se termina éste, se retorna al punto de llamada.

Llamar a una función asíncrona desde otra función asíncrona

A la hora de llamar a una función asíncrona desde otra función asíncrona, la primera idea que nos puede venir a la cabeza es hacer

// ATENCION, ESTE CODIGO NO FUNCIONARA CORRECTAMENTE

async void AsyncFnc1() {
    int retval;

    [...]
    AsyncFnc2( (ob,res) => {
        retval=AsyncFnc2.end();
        AsyncFnc1.callback();
    });
    yield;
    [...]
}

Aparentemente, este código lanzaría AsyncFnc2 y suspendería la ejecución de AsyncFnc1, pero de manera que, al terminarse la ejecución de AsyncFnc2, continuaría la ejecución de AsyncFnc1.

Por desgracia, ese código es probable que no funcione correctamente, como mínimo en un caso concreto: si, por la razón que sea, la función AsyncFnc2 finaliza sin llamar a yield al menos una vez, se llamará antes a AsyncFnc1.callback() que al yield, por lo que el código fallará. Una solución a este problema sería utilizar Idle.add(AsyncFnc1.callback) en su lugar, pero sólo funcionará si tenemos un Main Loop en nuestro programa, pues será éste quien llame al callback después de que la función asíncrona retorne tras ejecutar el yield.

Afortunadamente, los diseñadores de Vala eran conscientes de que es muy común llamar a una función asíncrona desde otra, por lo que simplificaron notablemente este caso concreto. Así, para llamar a AsyncFnc2 desde AsyncFnc1, de manera que ésta última continúe su ejecución cuando acabe la otra, sólo hay que hacer

async void AsyncFnc1() {
    int retval;

    [...]
    retval=yield AsyncFnc2();
    [...]
}

Otra ventaja es que, en este caso, no necesitamos llamar a AsyncFnc2.end() para obtener los resultados, porque se hace directamente.

El flujo de ejecución sería así:

Vemos que desde el Main Loop llamamos a nuestra primera función asíncrona, AsyncFnc1, y después de un trozo de código llamamos, mediante yield, a nuestra segunda función asíncrona, AsyncFnc2. En ésta ejecutamos algo de código y llegamos a un yield. Sin embargo, éste no retorna a AsyncFnc1, sino a la llamada anterior. Esto es así porque AsyncFnc1 lo que quiere es dormir hasta que AsyncFnc2 termine.

También vemos que para reanudar la ejecución es preciso llamar a AsyncFnc2.callback(). Esto debe tenerse muy en cuenta: en este instante es incorrecto llamar a AsyncFnc1.callback(). Por eso es fundamental que cada función asíncrona se encargue de programar su llamada para recuperar el control, y no delegarlo a funciones externas, pues es muy fácil cometer errores.

Cuando AsyncFnc2 llega al final, se cede el control al código de AsyncFnc1, que sigue ejecutándose, y al terminar, se llamaría a la función de callback de finalización (si la hubiera), y seguiría la ejecución justo a continuación de la llamada a AsyncFnc2.callback() (que, en este caso, simplemente seguiría con la ejecución del Main Loop).

Casos de uso de funciones asíncronas

El primer caso de uso de las funciones asíncronas es para llamar a otras funciones asíncronas. Esto, que puede parecer una perogrullada, toma sentido en cuanto descubrimos las funciones asíncronas de Gio. Un ejemplo es el de File.copy_async: este método de la clase File copia un fichero de manera asíncrona. De no existir, tendríamos que crear un hilo y ejecutar en él la función síncrona de copia, porque de no hacerlo así, si el fichero fuese muy grande la interfaz gráfica de nuestro programa se quedaría congelada durante la operación.

Hay dos maneras de llamar a estas funciones asíncronas: la primera es la clásica, incluyendo un callback (bien como puntero a función, bien como función anónima o closure) que se llame cuando termine la operación; la segunda, más cómoda en según que casos, es llamarla mediante yield desde una función asíncrona de Vala. En este segundo caso hay que saltarse el parámetro del callback.

El segundo caso de uso es para llamar a servicios externos mediante DBus. De esta manera podemos aprovechar el tiempo entre el envío de la petición y la llegada de la respuesta. Para ello, basta con añadir async en la definición de la interfaz DBus. Un ejemplo de como definir la interfaz DBus para formatear un disco, mediante el demonio UDisks:

[DBus (name = "org.freedesktop.UDisks.Device")]
interface Device_if : GLib.Object {
	public abstract async void FilesystemCreate(string type, string[] options) throws IOError;
}

Por desgracia, en este caso concreto no podemos aprovechar la funcionalidad de la llamada mediante yield, debido a que existe un timeout en las llamadas a métodos DBus de, aproximadamente, 25 segundos, y se necesita más tiempo para formatear algunos soportes. Se supone que se puede ajustar este timeout mediante un modificador de Vala, pero después de consultar en la lista de correo y de buscar en internet, no he conseguido que funcione. Si alguna alma caritativa nos puede iluminar…

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é inactivo (en el caso de una aplicación gráfica, cuando no hay eventos que procesar en la cola). La solución consiste en crear una función asíncrona que realice la tarea, insertando llamadas a yield de manera regular. Para que la función se despierte cuando la cola está vacía, usamos Idle.add() para llamar al método .callback() de nuestra función asíncrona, así:

public async void AsyncFnc() {

    // Inicialización de variables y demás
    [...]

    // Comienza la tarea
    while(cond==true) {

        // Realizamos una iteración de la tarea
        [....]

        // Avisamos al Main Loop que queremos que nos despierte
        // cuando no haya eventos pendientes
        Idle.add(AsyncFnc.callback);

        // Y devolvemos el control al búcle principal o Main Loop
        yield;
    }

    // La tarea ha finalizado
    // Limpiamos todo
    [...]
}

Por supuesto, podemos utilizar también un temporizador en lugar de Idle, o cualquier otro sistema que decidamos.

Un detalle interesante que se puede ver en este ejemplo es que la llamada a yield puede ir dentro de un bucle while o for sin ningún problema.

Por último, también son útiles para sincronizar threads. El truco en este caso está en almacenar un puntero al método de callback de la función asíncrona que queremos sincronizar, lanzar el thread, y al final de éste, añadir dicho callback a la cola de mensajes. El esquema es éste:

async void AsyncFunc() {

    // Aquí almacenamos el método .callback() de nuestra función asíncrona
    SourceFunc callback = AsyncFunc.callback;

    // Creamos la función para el thread. La hacemos anónima (closure) para que tenga acceso a la
    // variable local callback.
    ThreadFunc<void*> run = () => {
        // Código del thread. Aquí hacemos las operaciones deseadas
        [...]

        // Aquí ya hemos terminado las operaciones, así que
        // añadimos el método .callback() a la cola para que se llame inmediatamente
        Idle.add((owned) callback);
        return null;
    };

    // Lanzamos el thread
    Thread.create<void*>(run, false);

    // Y esperamos a que se llame a nuestra función callback
    // que será cuando termine el thread
    yield;
}

En la documentación oficial se encuentran tres ejemplos de funciones asíncronas, muy útiles para entender aún mejor esta útil característica de Vala. En concreto aparece un ejemplo del método de sincronización de threads, donde se puede ver mucho mejor la sintaxis concreta.

Usuarios perdidos

Acabo de descubrir que durante la migración del servidor se han perdido los usuarios registrados, así que tendréis que volver a daros de alta para poder hacer comentarios (exigir registro es la única manera de reducir el spam a niveles manejables).

Actualización: la opción de permitir darse de alta estaba desactivada, por lo que era imposible dejar comentarios. Acabo de corregirlo.