🚀 go-pugleaf

> >> documetacion...El codigo es muy sencillo, y no parece que
> >> revista tiempo de proceso... Mucho menos que el polling.
> >
>         // mientras haya datos disponibles... do!
>         while(entrada.avail()>0){
>             codigo !!!!!!
>         }

Dos posibilidades:

(1)
Si pretendes hacer lo que creo (leer TODOS los datos en el bucle
while), ese c�digo est� mal. Aparte de que el m�todo correcto es
available(), y ni avail(), la forma de detectar el fin de archivo, o
el momento en que debes dejar de leer no es mediante available(), sino
mediante la comprobaci�n de que read() devuelve -1 o de que
read(byte[]) devuelve un n�mero menor o igual a cero.

======================
InputStream is = ...;
byte[] buffer = ...;
int cuenta;
while((cuenta=is.read(buffer))>0){
    // Hacer cosas con los datos le�dos.
    }

is.close();
// Aqu� har�amos algo para avisar al resto de threads de que los datos

// ya han sido le�dos
=========================

Ten en cuenta que available() puede devolver 0 (porque los paquetes de
datos tarden en llegar debido a la saturaci�n de la red) pero que aun
queden cosas por leer del socket.

(2)
Si lo que en realidad quieres es que el thread haga su trabajo (antes
de entrar en el while) y al final de su bucle principal lea lo que
haya disponible del socket , entonces es normal que consuma recursos.
Est�s usando el 100% de la CPU en el bucle principal. No se de qu� te
extra�as. De hecho, est�s usando la t�cnica de "polling", que en
teor�a quer�as evitar.

Ser�a mejor que pusieras un trozo del programa menos "mutilado", para
que veamos donde se est� consumiendo CPU. Ten en cuenta que a menos
que hagas un Thread.sleep() en alg�n sitio, o hagas un lectura
bloqueante en el socket (sin comprobar available()), tu thread nunca
descansa, y nunca deja de consumir recursos.

Chano.