🚀 go-pugleaf

Juan Gonzalo de Silva Medina wrote:
 
> El "problema" es que no quiero que las aplicaciones clientes (que
> generan el log) se esperen a que todo esto se haya realizado, sino que
> una vez recibido el registro de log por el cliente de socket, este
> "libere" a dicha aplicacion (no quiero que el socket se cierre).
> 
> En principio pense que lo mas comodo era tener una cola (como las
> ventanas) que recibiesen los eventos y estos se procesasen
> asincronamente cuando fuese necesario. 

Me parece que esto es el enfoque correcto. La gesti�n de eventos de log
puede ocurrir en su propio thread. Los otros threads simplemente
depositan el evento en la fila y siguen sin esperar. A lo mejor el
thread que procesa eventos de log est� normalmente dormido, pero
"despierta" cuando hay eventos que gestionar. Todo esto es de libro de
texto...

> No encontre informacion sobre colas de usuario.

Una cosa que hacer ser�a mirar el c�digo de las clases pertinentes del
AWT e intentar adaptarlo. Por ejemplo, el c�digo fuente de:

java.awt.EventDispatchThread
java.awt.EventQueue
java.awt.EventQueueItem

(Todo el c�digo fuente de las clases core est�n en el src.zip en la
distribuci�n del JDK.)
 
> Asi, pense que lo mejor era construirmela yo, esto es, creando un vector
> que almacene los mensajes (sincronizado), y emitiendo un evento a un
> hilo que lee esta cola (dispatch event).
> 
> En este punto carezco de informacion y tengo varias dudas:
> 
> �puedo parar el hilo con un semaforo para que otro lo active?

S�, por supuesto. Tendr�as que mirar los m�todos wait() y notifyAll() de
java.lang.Object. El esquema abajo es aproximadamente la idea, supongo.

class MiCola extends Thread {
   public synchronized void run() {
       while (true) {
          MiEvento evento = next(); //implementado como quieras.
          gestionaEvento(evento); // implementado como quieras.
          if isEmpty() wait();<-----esperar hasta alguna notificaci�n
       }
   }
   public agregarEvento(MiEvento evento) {
      add(evento); // implementado como quieras.
      notifyAll();<----dar la notificaci�n que hay un cambio en el
objeto.
   }

// el resto de la implementaci�n
}

> �puedo dormir el hilo y esperar que haya otro que lo despierte, y que
> esto funcione?

En el poquit�n de c�digo arriba, lo que pasa es que cuando la cola est�
vac�a, el m�todo sincronizado invoca wait() y as� se duerme hasta que
reciba alguna notificaci�n del cambio de estado del objeto. As�, cuando
otro thread, invoque agregarEvento(), invoca el notifyAll() que vuelve a
despertar el otro thread del run(). Cuando la cola est� vac�o de nuevo,
el hilo se duerme.

> �existen mensajes asincronos entre objetos?

Quiz� sea esto arriba lo que buscas. Si simplemente tienes dos Threads,
uno que produce eventos y el otro que responde, otro esquema interesante
ser�a los "pipes". Valdr�a la pena mirarte el 
java.io.PipedInputStream y el java.io.PipedOutputStream.

El thread asociado con el PipedOutputStream puede simplemente a�adir
datos al stream y seguir sin esperar. El otro thread asociado al
PipedInputStream procesa los datos en otro thread.

Pero eso supone que hay una relaci�n 1-1 entre el thread que produce los
eventos y el que los procesa. Me parece que lo que describes es un
esquema en que tienes multiples threads, cada uno representando un
cliente, es decir multiples threads que pueden producir eventos, pero un
solo thread que los gestiona. 

> 
> Revise el libro "thinking in Java" pero no encontre nada sobre estos
> temas... :-(.

Es un buen libro. Sobre todo por el precio. ;-)

Acabo de mir�rmelo y me parece que abarca bastante bien este tema. Es el
cap�tulo 14 titulado "Multiple Threads". En la versi�n Acrobat que
tengo, hay ejemplos de este tipo de cosa alrededor de p�gina 620 y pico.

�Tienes el java tutorial de Sun tambi�n? (tambi�n es bueno por el
precio.) Tiene una se

http://java.sun.com/docs/books/tutorial/

Espero que esto ayude un poco. 

Jonathan Revusky
-- 
Available for Java and Delphi Consulting
Make your .class files double-clickable
with SmartJ
http://www.bigfoot.com/~crystalline.solutions