🚀 go-pugleaf

Juan Carrasco <jcarras@glup.uv.es> wrote:
>   Lo ideal ser�a que cada socket se enterara de cuando dispone de datos, y
> en un programa puedo tener varios sockets funcionando, por lo que con SIGIO
> me har�a falta un mecanismo extra para saber que sockets existen y detectar
> el que tiene datos, adem�s de que no se que capacidades tengo para llamar
> funciones desde un manejador de se�al.
Eso es facil. Mira la funci�n select. Pro una parte usas SIGIO para que
te informen (eso no lo he usado... en el peor caso, el SIGIO te lo puede
enviar una hebra).
Al producirse un SIGIO, ya sabes que al menos un descriptor, tiene datos para
leer.
Pues bien. select te permite saber, cual, de un conjunto de descriptores, tiene
datos pendientes de leer.
De esa manera, y con un poco de habil programaci�n, es posible crear tus 
ansiadas clases.
Veamos.
Supongamos que en Linux ni siquiera existe un modo en el cual, al haber datos 
pendientes te mande un SIGIO.
Creas una hebra, dedicada exclusivamente a proporcionar eventos as�ncronos para
poder detectar los eventos aparte del programa principal (TODOS los eventos,
incluidos movimientos de raton, pulsaciones, lectura de sockets, etc.)
Bien... La lectura de dichos eventos, salvo casos excepcionales, se realiza
leyendo de un conjunto de descriptores. Cuando ocurre un evento, este manda los 
datos al fichero referenciado por un descriptor.
Por lo general en Unix, los ficheros "especiales" de este tipo (sockets, 
terminales, dispositivos de caracteres) suelen ser bloqueantes.
Es decir, cuando se intenta leer de ellos y no hay datos que proporcionar (se
leen eventos del raton pero este no se mueve) el proceso se queda parado y
no lee.
Ahora bien... haciendo uso de la funci�n select, se puede estar esperando por
la lectura de varios descriptores a la vez, y en el momento de que en alguno
haya datos, este se desbloquear�. Tambi�n se pueden revisar de manera no
bloqueante, consultando si hay datos disponibles o no. Sin embargo si dedicamos
una hebra solo al asunto no hay raz�n para hacerlo as�. Nos vale con bloquear
y en el momento que hay algo que leer de alguno de los descriptores de 
desbloquear� y podr�s leer de el.
Ahora, tan solo debes hacer tus clases de la siguiente manera...
Al arrancar se crea una hebra especial para eventos as�ncronos.
Cuando dicha hebra detecta que un descriptor tiene datos para leer, leer� los
datos, los introducir� en el buffer correspondiente y ver� en alg�n tipo de
estructura, la funci�n que debe mandar al hilo principal que debe ejecutar ante
la lectura de dicho perif�rico.
Manda una se�al al hilo principal que consultar� dichos datos y ejecutar� la
funci�n adecuada de tratamiento.
Las se�ales se parecen a las interrupciones del DOS. Tras ejecutarse, recuperan
la posici�n anterior de ejecuci�n.
Hay que tener cuidado. Si empleamos se�ales el hilo principal JAMAS debe usar
lecturas bloqueantes, ya que las se�ales las rompe y estas pueden no funcionar.
La sincronizaci�n entre hilos bien se puede hacer mediante sem�foros IPC o
usando alg�n tipo de variable que haga las veces de sem�foro (son hilos y 
comparten variables globales)

Espero haberte dado ideas.
Suerte.