🚀 go-pugleaf

Juan Carrasco <jcarras@glup.uv.es> wrote:

>  Gracias, ya me habia planteado una opci�n parecida, pero no acaba darme
> mucha confianza, ten en cuenta que no se cuantos sockets van a haber. Lo
> bueno seria "dar de alta" el socket a alguien que se encargue de realizar el
> select, o utilizar un hilo por cada socket para escuchar. �Cual crees t� que
> puede ser la mejor opci�n, un objeto o clase al que haya que decirle que
> sockets hay o uno o m�s hilos por socket para las operaciones? Podr�a

Lo normal es que manejes todos los sockets (y descriptores) desde un solo hilo.
La funci�n de crear socket en el hilo principal, hace una llamada especial al
hilo de soporte as�ncrono. Este da de alta al descriptor en cuesti�n dentro
del select y crea una referencia a la funci�n a la que deber� llamar si
recibe datos.
El m�ximo n�mero de descriptores es de 1024, as� que un array de punteros es
de 4Kb. Tampoco es mucho hoy en d�a.
De hecho esto mismo lo puedes hacer sin hebras, usando el m�todo de examinar
cada cierto periodo de tiempo. Usando el alarm y atendiendo a la se�al cada
1 cent�sima de segundo puedes examinar si hay alguna operaci�n que realizar
en los descriptores y seguir con lo que estabas.
Sin embargo hay que reconocer que ser�a preferible que el kernel tuviese algo
para no tener que solucionarlo con un sistema tan "chapuza".
Pero funcionar, funciona. Te lo aseguro.
Eso s�. Tienes que jugar con las m�scaras de las se�ales para asegurarte que
el alarm no se parar� ante una llamada bloqueante en medio de la ejecuci�n
normal. Si hubiesen algunos tipos de llamada que pudiesen bloquear el alarm
durante demasiado tiempo, la soluci�n de hebras ser�a m�s recomendable.

En linux no puedes crear demasiadas hebras ya que estas son tratadas como 
procesos normales.