🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.lenguajes.java
Article #29838

Re: problemas con los threads

#29838
From: Jorge Baez
Date: Fri, 17 Oct 1997 00:00
84 lines
3537 bytes

Chano G�mez escribi� en mensaje <34468E1C.58E70E8D@ran.es>...
>> >> 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(),

Parece que eso del nombre es lo de menos, todos sabemos como se escribe...

> 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.

Bueno, esto no es del todo cierto...
Los paquetes llegan a la cola de entrada de forma secuencial, y hasta que NO
acababa toda, available() es CERO. El tama�o maximo de paquete es LIMITADO,
y al sobrepasarlo la informacion se distribuye en varios paquetes. Hasta que
no este todo, available() sera CERO.

De todos modos te recuerdo que: InputStream.available() devuelve el numero
de bytes disponibles....

>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.

Eso es algo a lo que yo hago referencia arriba...

>(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.

Mucha razon tienes.... Mi idea era manejar un interface por eventos, y
mantener en background al thread. La funcion run() tiene el codigo del
thread...
Parece que esto no es asi.
el codigo es:

public void run(){
  try {
   /**
   * Bucle de recogida de datos
   **/
   while(conectado sea true) {
        /**
        * comprobamos si hay datos y cuantos
        **/
        int total=entrada_datos.available();
        if(total>0) {
                // PROCESO de recogida de
                // entrada de datos...
                 byte[] buffer=new byte[total];

                 entrada_datos.read(buffer,0,total);
                 ....
                    MyCode
                    Es sencillo, casi no consume.
                ...
        }  // del  IF
    } // try
    catch(talycual) { }
} //  Run

  Si no hago 'runnable' my applet, y hago que el thread corra sobre ella de
forma menos directa, Consumira menos recursos?
  Alguna idea para recoger todos los datos de otra forma??????

__giGGler__
Technical Details
Message-ID: <627jse$opd$1@eubuf21.eu.concert.net>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <621phh$j4n$1@eubuf21.eu.concert.net> <3444F36C.5A2A0EB4@ran.es> <624qaa$bc4$1@eubuf21.eu.concert.net> <34468E1C.58E70E8D@ran.es>

Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII
X-Google-Thread: 1116f3,81ae46b387e0e534
X-Google-Attributes: gid1116f3,public
From: "Jorge Baez" <giggler@recoletos.es>
Subject: Re: problemas con los threads
Date: 1997/10/17
Message-ID: <627jse$opd$1@eubuf21.eu.concert.net>
X-Deja-AN: 281230678
References: <621phh$j4n$1@eubuf21.eu.concert.net> <3444F36C.5A2A0EB4@ran.es> <624qaa$bc4$1@eubuf21.eu.concert.net> <34468E1C.58E70E8D@ran.es>
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Organization: A poorly-installed InterNetNews site
Newsgroups: es.comp.lenguajes.java