Junio
2007
Programación multihilo, fork y compartir variables [SOLUCIONADO]
Estoy preparando una nueva versión de tcos-devices (bautizada como tcos-devices-ng) mucho más simple ya que se crea un menú en la barra de tareas dinámicamente con las unidades encontradas en el terminal ligero...
ACTUALIZACIÓN:
Ya está disponible un pequeño video (en flash) con el funcionamiento del nuevo tcos-devices-ng.
Por cada menu aparece un submenú con las opciones de montar y desmontar y para ser un poco más intuitivo, la opción que se puede hacer, activada.
Hasta aquí bien....
Resulta que necesito que la aplicación tenga dos hilos de ejecución, el primario es el que carga el menú, se conecta al terminal para ver dispositivos y se encarga de cdrom y disquetes, necesito otro segundo hilo que cada x segundos (3 es un buen número) compruebe los eventos udev del terminal.
Para lanzar este segundo hilo y que no interfiera con el primero hay varias opciones:
La opción del thread es la más lógica pero no he sabido porqué el thread queda congelado hasta que no termina la aplicación principal ( gtk.main() )
Como último recurso queda la segunda opción, lanzar un thread y un fork, pero nos encontramos de nuevo con el problema de no poder modificar las variables...
¿Para que demonios voy a modificar las variables de una aplicación desde otra?
Pues para algo tan «cool» como cuando pinchemos una memoria USB, udev genere el evento, el "escuchador udev" lo detecte y se añada al menú un nuevo elemento con la memoria (modelo, marca) y la posibilidad de desmontarla (se montaría automáticamente)
Llegados a este punto he empezado a buscar metodos que me sirvan para que los dos hilos hablen entre si:
¿Sugerencias?
UPDATE 20:18:
Ya me vale la tontería, escribiré mil veces que hay que avisar al módulo gtk cuando vamos a usar hilos con «gtk.gdk.threads_init()», ya lo tengo funcionando con dos simples threads, en breve un screencast...
ACTUALIZACIÓN:
Ya está disponible un pequeño video (en flash) con el funcionamiento del nuevo tcos-devices-ng.
Por cada menu aparece un submenú con las opciones de montar y desmontar y para ser un poco más intuitivo, la opción que se puede hacer, activada.
Hasta aquí bien....
Resulta que necesito que la aplicación tenga dos hilos de ejecución, el primario es el que carga el menú, se conecta al terminal para ver dispositivos y se encarga de cdrom y disquetes, necesito otro segundo hilo que cada x segundos (3 es un buen número) compruebe los eventos udev del terminal.
Para lanzar este segundo hilo y que no interfiera con el primero hay varias opciones:
- lanzarlo en un nuevo thread
- lanzarlo en un thread y hacer un fork
- usar un parámetro para arrancar uno u otro y lanzar los dos
La opción del thread es la más lógica pero no he sabido porqué el thread queda congelado hasta que no termina la aplicación principal ( gtk.main() )
Como último recurso queda la segunda opción, lanzar un thread y un fork, pero nos encontramos de nuevo con el problema de no poder modificar las variables...
¿Para que demonios voy a modificar las variables de una aplicación desde otra?
Pues para algo tan «cool» como cuando pinchemos una memoria USB, udev genere el evento, el "escuchador udev" lo detecte y se añada al menú un nuevo elemento con la memoria (modelo, marca) y la posibilidad de desmontarla (se montaría automáticamente)
Llegados a este punto he empezado a buscar metodos que me sirvan para que los dos hilos hablen entre si:
- pipes (las pruebas que he hecho no me acaban de convencer ya que en la aplicación gráfica necesitaría otro "escuchador" del pipe)
- sockets (demasido complicado, además este proceso se ejecuta una vez por cada cliente...)
- memoria compartida, colas de mensajes... (muchos procesos, complica el tema)
- guardar/leer variables desde un archivo (metodo más grotesco pero que en teoría podría salvar el problema)
¿Sugerencias?
UPDATE 20:18:
Ya me vale la tontería, escribiré mil veces que hay que avisar al módulo gtk cuando vamos a usar hilos con «gtk.gdk.threads_init()», ya lo tengo funcionando con dos simples threads, en breve un screencast...
Quizás te convenga usar avahi para esto, aunque también puede ser una tontería lo que acabo de decir...
En una solución en local (en el mismo equipo) se hubiera podido usar millones de cosas, en una red con todo instalado también, pero....
En un red de terminales ligeros donde se minimiza al máximo los requerimientos de RAM no se debería meter más de lo necesario, no lo he probado pero añadir avahi al terminal podrís subir el consumo de ram bastante...
De todos modos gracias por la idea porque investigaré ya que los temrinales usan PulseAudio desarrollado por el mismo desarrollador de avahi.
Nunca imagine las cosas sorprendente que se puden hacer con debian,tengo que admitir que aunque soy una novata en este asunto eh podido comprender algunos de tus articulos es por ello que te doy las gracias por abrir este tipo de espacios,y algun dia esperare ser como tu