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´
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://twitter.com/ajlopez
2010/10/6 Guillermo Schwarz <[email protected]>
Autopoyesis es copia, no autoorganización. Que conduzca a la autoorg
anización es otra cosa.
¿Como es eso de que te llamas Angel Java Lopez e implementas un Smal
ltalk 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 c
uando se llena la cola también), lo interesente es que los objetos e
nviadores 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 se
r en slashdot.
Saludos,
Guillermo.
2010/10/6 Angel Java Lopez <[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 ob
jeto agente va atendiendo los mensajes que le llegan de a uno (actua
lmente, en un thread aparte, para cada agente, pero podria cambiar l
a implementacion). También implementé que la cola de mensajes del a
gente, tenga un tamaño limitado, asi si hay varios que producen mens
ajes para ese agente, y la cola de mensajes se llena, automaticament
e se van suspendiendo a los threads/procesos del objetos enviadores,
reanundando su actividad ni bien tienen lugar en para dejar su mens
aje en la cola de mensajes del agente. Espero producir asi una auto-
regulacion de las velocidades de produccion y atencion de los mensaj
es.
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
[2] http://ajlopez.wordpress.com/category/ajsharp/
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
2010/10/6 Guillermo Schwarz <[email protected]>
Suena a que tiraste la toalla.
Lo de la intencionalidad está bien para los seres humanos, pero en e
l caso de la naturaleza en vez de intencionalidad hay oportunidad (n
ichos ecológicos) que son llenados por elementos con autopoyesis http://culturitalia.uibk.ac.at/hispanoteca/lexikon%20der%20linguistik/ao/AUTOPOIESIS%20Autopoyesis.ht
m
Esto es interesante para el punto en discusión porque al ser Alan Ka
y un biólogo molecular y al tratar de modelar los objetos como si fu
eran células que responden a mensajes, la idea era que el comportami
ento "emergiera". Esto es también uno de los objetivos de eXtreme Pr
ogramming, que emerja la auto-organización del programa, por más ext
rañ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.
Saludos,
Guillermo.
On Tue, Oct 5, 2010 at 11:14 PM, Andres Valloud <[email protected]
> wrote:
> Si todas las cosas dependen de las intenciones, ¿dónde dejas la le
y 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]
To unsubscribe from this group, send email to
[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
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[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
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[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
