En Smalltalk lo que dices de migrar un objeto de una máquina a otra es (o debería ser) trivial.
1. Se serializa la clase en la máquina 1 (representación en texto). Hay bibliotecas para hacer eso que recojen incluso todos los objetos relacionados. Se debe incluir el método y la línea que estaba ejecutando, eso es trivial con thisContext. 2. Se envía a la máquina remota, se deserializa y se le indica al "thisContext" que continúe ejecutando. No lo he probado, pero debería funcionar. ;-) Lo que sí he probado es tener objetos remotos persistentes. Es muy parecido. 1. Creo una clase PersistentRemoteDictionary que serialice los objetos y lso envíe a través de un socket a un servidor ejecutando C++ o Java. 2. En el servidor coloco GDBM o JDBM e implemento put y get. (#at:put: y #at: sería el equivalente en Smalltalk). Listo. ;-) Ahora cualquier Dictionary se puede reemplazar por PersistentRemoteDictionary y puedo tener todos los clientes Smalltalk que quiera compartiendo los objetos a través de un servidor, como un PoorManObjectDatabase y el desempeño es como correr local, porque los sockets son super eficientes y JDBM también. Saludos, Guillermo. 2010/10/6 Angel Java Lopez <[email protected]> > 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]<clubsmalltalk%[email protected]> > > http://www.clubSmalltalk.org > -- Saludos cordiales, Guillermo Schwarz Sun Certified Enterprise Architect -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
