Hola gente! Guillermo, no, todavia no lo he intentado, lo de los objetos remotos.
Con respecto a los threads del sistema operativo, no habria problema en reimplementar el dispatching de los mensajes a los agentes de esta forma: - En vez de tener una cola por agente, hay una sola cola con <mensaje>, con <mensaje, receptor> - N threads consumiendo esa cola, y enviando el mensaje al agente correspondiente. De nuevo, es un cambio en la VM, nada de lo escrito en AjTalk con agentes deberia cambiar, tengo los tests de TDD para asegurarme que eso se cumpla (espero ... :-). No estoy tan seguro que los threads del sistema operativo sean los mismos que la VM: una VM tiene un concepto de thread mas logico aun. Solo un thread de la VM activo necesitaria un thread del sistema operativo. Por lo menos, en .NET, hay una propiedad del thread llamada ManagedId, que recuerde, que no parece tener una aplicacion directa a tal thread del sistema operativo. Lo de objetos remotos, lo tengo en AjShap, todavia me falta ponerlo en AjTalk. Me gustaria: - Definir una clase en la maquina M, poder instanciar un nuevo objeto en la maquina N (viajando de alguna forma la definicion de la clase definida). - Definir una clase en la maquina M, crear una instancia en esa maquina, y hacerla viajar a la maquina N (mas dificil: si la instancia tiene referencias a otros objetos, que objetos hacemos viajar a N y cuales permanecen como una referencia remota en N al objeto en M?). Si traslado lo de AjSharp, podria ponerlo en AjTalk como en el nodo M MiClase at: <objetoquedescribeelnodoremotoN> new: .... Me quedaria en M un objeto cuyos mensajes son reenviados a la instancia recien creada del nodo N. Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez Nos leemos! Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez 2010/10/6 Guillermo Schwarz <[email protected]> > Tengo entendido que la mayor parte de los sistemas operativos tienen un > limite de entre 256 y 1024 threads, e incluso algunas versiones de linux > soportan 8192 threads y no tienen problemas de desempeño. > > Pero una vm de smalltalk debe tener unos 5000 objetos activos (no lo he > revisado pero no creo que pueda tener menos), y un seaside con 10 mil > conexiones activas se iría de espaldas rapidamente usando tu diseño. > > Si queremos tener arquitecturas escalables, debemos limitar el uso de > recursos que a nivel del sistema operativo son limitados. > > A todo esto, tu diseño parece que podría de manera trivial publicar objetos > para ser llamados de manera remota. ?lo haz intentado? > > Saludos, > Guillermo Schwarz. > > El 06-10-2010, a las 11:18, Angel Java Lopez <[email protected]> > escribió: > > Hola gente! > > Guillermo, me parece interesante ponerlo ya a nivel de la expresividad de > un lenguaje, que esa conducta "envio mensaje y sigo con mis cosas" se vea > como natural, ya puesto en el mensaje. Podria implementar eso directamente > en el proceso de mensaje de agente1, para que sea transparente para el > llamador, pero me parecio interesante (me tomo menos de una hora, usando > TDD) directamente ponerlo en la VM. > > Los threads en .NET son, digamos, logicos. Lo mismo, que recuerde, en Java. > Las VM luego mapearan los threads a lo que haya disponible en los sistemas > operativos, hardware, y demas que se encuentren hoy o el dia de maniana. > Bloquear un thread, no lo deja "ocupado". Y aun los threads de un sistema > operativo, son, digamos, virtuales. Lo real es la asignacion de un thread a > un procesador. Lo que si consume un thread es memoria en algun lado, para > mantener su estado, aun cuando este suspendido. Pero imagino que la parte > del leon, en eso, se la lleva el proceso, mas que el thread. > > Puedo copiar objetos, pero la idea es: si copio objetos y los coloco en la > misma maquina, puedo mejorar algo el rendimiento de la aplicacion. Pero mas > interesante de explorar, es copiar los objetos en OTRAS maquinas, de forma > que sea transparente > > agente1 doSomething: param1 with: .... > > que agente1 este local o remoto. Por supuesto, el programador de la > aplicacion debera ver que esa llamada tiene un costo. Pero mi idea, es que > si el agente1 es local o remoto, sea algo que se decida en otro lado del > codigo (o configuracion), sin tener que cambiar el codigo de la aplicacion. > De esta forma, puedo probar un algoritmo, aplicacion, de forma local, y > luego, comenzar a distribuirla y hacer escalamiento horizontal. El ejemplo > que uso es un Web Crawler. Ahi en las referencias que envia, habia algunas > implementaciones. > > Tambien, la idea (tengo algo en AjSharp implementado) es que agente1 en > realidad, sea local, y haga una especie de load balancing con varios objetos > remotos. Por ejemplo, en un web crawler, podria enviar > > downloader downloadUrl: ´ <http://mycompany.com>http://mycompany.com´ > > y downloader por abajo, envia ese trabajo (bajar tal pagina) a si mismo, o > enviarlo a cualquiera de los 400 downloaders que tendria en mi > laboratorio... mmmbuajjajaja... :-) > > Tanto AjSharp como AjTalk (y otros Aj ... :-)... como AjBasic, AjGenesis, > AjLisp, AjProlog....), se pueden reimplementar en Java: practicamente no > estoy usando nada especial de .NET, por ahora. Por ejemplo, cuando comence a > escribir algunos de esos, en .NET tenia Generics y en Java todavia no: y no > use generics, recien ahora lo estoy usando minimamente. En el caso de > objetos distribuidos, si, hay algo que uso para hacerlo rapido: Remoting > binario en .NET, tendria que investigar el estado del arte de la > serializacion en Java. > > Nos leemos! > > Angel "Java" Lopez > <http://www.ajlopez.com>http://www.ajlopez.com > <http://twitter.com/ajlopez>http://twitter.com/ajlopez > > 2010/10/6 Guillermo Schwarz < <[email protected]> > [email protected]> > >> Autopoyesis es copia, no autoorganización. Que conduzca a la >> autoorganización es otra cosa. >> >> ¿Como es eso de que te llamas Angel Java Lopez e implementas un Smalltalk >> asíncrono en C#? ;-) >> >> ¿Porqué no usas colas de mensajes y un colocas los objetos sobre un thread >> en la medida que lo van necesitando? Sí, lo de lo mensajes lo hiciste, y lo >> del watermark (que se queden pegados los enviadores cuando se llena la cola >> también), lo interesente es que los objetos enviadores se queden bloqueados >> pero los threads no, para reutilizar los threads con otros objetos. >> >> (Eventualemtne sospecho que los sistemas operativos harán esto, pero en el >> intertanto...) >> >> Podrías además crear copias de los objetos que reciben los mensajes para >> que operen más rápido. Claro que todo esto serían un overkill si no lo >> aplicas en algo que lo necesite, como por ejemplo pdoría ser en slashdot. >> >> Saludos, >> Guillermo. >> >> 2010/10/6 Angel Java Lopez < <[email protected]>[email protected] >> > >> >>> Hola gente! >>> >>> El termino autopoyesis me parece innecesario, ya estaba el termino >>> autoorganizacion. Con eso basta. Hmmm... supongo que el clasico a leer sobre >>> la vida, es el clasico de Monod, Azar y Necesidad. Supongo que un tema >>> relacionado a intencionalidad en organismos y evolucion biologica, seria >>> teleologia. Leeria ahi a Ernst Mayr, que distingue varias acepciones de esa >>> palabra. >>> >>> Con respecto a los mensajes y su envio, en este thread Valloud habia >>> mencionado algo como "un objeto envia un mensaje a otro, y se queda >>> esperando la respuesta". Siempre me parecio interesante ir a explorar otro >>> camino "un objeto envia un mensaje a otro" y ya esta. Es asi como funcionan >>> las partes de los sistemas vivos. >>> >>> En mi caso, lo estoy implementando en mi VM pet project, AjTalk [1]. >>> Tengo algo como >>> >>> Object agent:.... >>> en lugar >>> Object subclass:.... >>> >>> Lo llame agent como podria llamarlo de otra forma. Entonces, los objetos >>> de esa clase que se define, tienen metodos, todo igual, pero cuando uno >>> envia un mensaje tipo >>> >>> agente1 msg: par1 with: ... "o lo que sea" >>> >>> el enviador del mensaje no se queda esperando la devolución. Y el objeto >>> agente va atendiendo los mensajes que le llegan de a uno (actualmente, en un >>> thread aparte, para cada agente, pero podria cambiar la implementacion). >>> También implementé que la cola de mensajes del agente, tenga un tamaño >>> limitado, asi si hay varios que producen mensajes para ese agente, y la cola >>> de mensajes se llena, automaticamente se van suspendiendo a los >>> threads/procesos del objetos enviadores, reanundando su actividad ni bien >>> tienen lugar en para dejar su mensaje en la cola de mensajes del agente. >>> Espero producir asi una auto-regulacion de las velocidades de produccion y >>> atencion de los mensajes. >>> >>> La idea, es conseguir tambien objetos y agentes distribuidos, como en >>> AjSharp [2], en varias maquinas. Pero para eso me falta un poco... :-) >>> >>> [1] <http://code.google.com/p/ajtalk>http://code.google.com/p/ajtalk >>> [2] <http://ajlopez.wordpress.com/category/ajsharp/> >>> http://ajlopez.wordpress.com/category/ajsharp/ >>> >>> >>> Nos leemos! >>> >>> Angel "Java" Lopez >>> <http://www.ajlopez.com>http://www.ajlopez.com >>> <http://twitter.com/ajlopez>http://twitter.com/ajlopez >>> >>> >>> 2010/10/6 Guillermo Schwarz < <[email protected]> >>> [email protected]> >>> >>>> Suena a que tiraste la toalla. >>>> >>>> Lo de la intencionalidad está bien para los seres humanos, pero en el >>>> caso de la naturaleza en vez de intencionalidad hay oportunidad (nichos >>>> ecológicos) que son llenados por elementos con autopoyesis >>>> <http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm> >>>> http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm >>>> >>>> Esto es interesante para el punto en discusión porque al ser Alan Kay un >>>> biólogo molecular y al tratar de modelar los objetos como si fueran células >>>> que responden a mensajes, la idea era que el comportamiento "emergiera". >>>> Esto es también uno de los objetivos de eXtreme Programming, que emerja la >>>> auto-organización del programa, por más extraño que resulte para una visión >>>> donde todo tiene intencionalidad. >>>> >>>> Un ejemplo de la vida real en el mundo del software son los proyectos >>>> open source. No existe una autoridad central que los organice y sólo en la >>>> medida que van teniendo éxito (más gente los usa) van mejorando. Desde el >>>> punto de vista de la "intencionalidad" eso no podría funcionar nunca, ni >>>> los >>>> wikis, etc. >>>> >>>> >>>> <http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.htm> >>>> Saludos, >>>> Guillermo. >>>> >>>> On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud <<[email protected]> >>>> [email protected]> wrote: >>>> >>>>> > Si todas las cosas dependen de las intenciones, ¿dónde dejas la ley >>>>> de >>>>> > las consecuencias indeseadas (unintended consequences)? >>>>> >>>>> No por querer volar logro despegar el chancho. >>>>> >>>>> Andres. >>>>> >>>>> -- >>>>> To post to this group, send email to <[email protected]> >>>>> [email protected] >>>>> To unsubscribe from this group, send email to >>>>> <clubsmalltalk%[email protected]> >>>>> [email protected] >>>>> >>>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Saludos cordiales, >>>> >>>> Guillermo Schwarz >>>> Sun Certified Enterprise Architect >>>> >>>> -- >>>> To post to this group, send email to <[email protected]> >>>> [email protected] >>>> To unsubscribe from this group, send email to >>>> <clubsmalltalk%[email protected]> >>>> [email protected] >>>> >>>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>>> >>> >>> -- >>> To post to this group, send email to <[email protected]> >>> [email protected] >>> To unsubscribe from this group, send email to >>> <clubsmalltalk%[email protected]> >>> [email protected] >>> >>> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >>> >> >> >> >> -- >> Saludos cordiales, >> >> Guillermo Schwarz >> Sun Certified Enterprise Architect >> >> -- >> To post to this group, send email to <[email protected]> >> [email protected] >> To unsubscribe from this group, send email to >> <clubsmalltalk%[email protected]> >> [email protected] >> >> <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org >> > > -- > To post to this group, send email to <[email protected]> > [email protected] > To unsubscribe from this group, send email to > <[email protected]> > [email protected] > > <http://www.clubSmalltalk.org>http://www.clubSmalltalk.org > > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
