Guillermo, ya me estoy yendo de la máquina, por lo que va el último mail
hasta el lunes. El objetivo es implementar 3, como te lo describí un par
de mails atrás (Process>>executeAt:port:). Para que eso sea
"transparente", desde mi punto de vista, vas a necesitar parte de 1) y
2), pero bueno, no se, eso es como yo lo implementaría, tal vez me estoy
complicando de mas. Respecto del otro mail que mandaste, me da la
sensación que lo que estás haciendo es RPC, no migración de un proceso a
otra máquina. Ah, y para hacer el tema del monitor de recursos (para que
un proceso que está consumiendo mucha CPU le deje paso a otro) fijate el
mensaje #forkAt: que toma como parámetro la prioridad a la que se va a
ejecutar el proceso.
Saludos!
Andrés
Guillermo Schwarz escribió:
Bueno pero me perdí, ¿qué estamos resolviendo?
1. EJB.
2. Proxy que cree clases que no existen en el servidor.
3. Migración de procesos en ejecución.
¿Cuál de los 3?
Por cierto, puede que VW tenga resuelto (1). J2EE también tiene resuelto (1)
pero es irrelevante porque no es open source (o no es compatible entre
diferentes vendors).
La idea es tener algo que no sea muy dificil de implementar y que todo el
mundo pueda probar de manera trivial.
Además no tiene sentido que sea dificl de implementar. La idea es simple,
debe ser simple o de otra manera se va a caer en casos de borde. La solución
que presenté incluso la puedo probar en un solo PC con 2 imágenes que
conversan entre sí. Para mí esa es la situación ideal para debuggear rápido
y luego que prueben otros la versión distribuida.
Saludos,
Guillerrmo.
2010/10/8 andres <[email protected]>
No, claramente no apunto a que implementes un Smalltalk nuevo; lo que digo
es que si ya usas un framework de distribución de objetos (tipo Opentalk o
rSt) la cosa ya está casi resuelta. Igual la parte de distribución por
referencia ya la tenés cocinada ("En el caso de usar proxy es trivial y
liviano y si el mecanismo funciona para uno, funciona para todos" -muy
interesante la última acotación-), sólo te falta resolver la distribución
por copia.
Respecto de las librerías me mataste, yo trabajo con VW no con Pharo :(
Saludos!
Andrés
Guillermo Schwarz escribió:
Oye, pero la idea no es hacerlo desde cero, sino tendría que hacer un
Smalltalk desde cero. No tiene sentido.
La serialización de objetos ya existe, los sockets también, los proxies
también. ¿Me hace falta algo aparte de juntar y pegar?
¿Alguien me puede recordar dónde están cada una de esas cosas? Tengo la
memoria un poco empolvada, aparte de que no tengo mucha experiencia en
Pharo.
Saludos,
Guillermo.
2010/10/8 andres <[email protected]>
Desconozco la licencia de Opentalk o si está portado a Pharo; igual pensé
que ibas a implementar todo de cero, total no es complicado, un par de
proxies nomás.
Sobre lo que decís en 2) la verdad no te sigo, pero parece sencillo;
deberás redefinir algún mensaje y serializar algún que otro compiled
method.
Y sobre #thisContext al menos en VW está y estoy casi seguro que en
Squeak
y Pharo también, así que dale con la implementación en Pharo. El lunes es
feriado pero tengo que trabajar igual, así que seguro voy a poder testear
tu
implementación.
Saludos,
Andrés
Guillermo Schwarz escribió:
1. Si OpenTalk ya lo tiene hecho, ¿es open source?
2. Si 1 está listo, implementar 2 es cosa de modificar doesNotUnderstand
para que pregunte si la clase está definida en el servidor (o en el
originador de la llamada, depende de cómo se quiera organizar el
asunto).
3. Recuerdo que había un Smalltalk en el que uno hacía "self yield" o
algo
así y dejaba el thread actual suspendido y le daba tiempo a otro de
ejecutar, utilizaba si no me equivoco thisContext y ProcessScheduler,
pensé
que era Smalltalk Express, pero al parecer no era porque no encontré
thisContext. ¿Alguien ha visto algo así?
Antes de ver eso habría que ver sobre qué vendor de Smalltalk se haría.
Yo lo haría sobre Pharo para que cualquiera lo pueda probar. Squeak se
me
hace difícil.
Saludos,
Guillermo.
2010/10/8 andres <[email protected]>
Te cuento lo que se de VisualWorks, tal vez Valloud tenga mas info:
1. Si, cubierto por Opentalk.
2. Opentalk cubre esto parcialmente, creo que se podía trabajar con
clases
como objetos remotos. Pero tenía sus vueltas. Sólo pensar que en las
dos
imágenes puede haber versiones distintas de la misma clase es un
problema.
3. No que yo sepa.
El tema es que cuanto mas "transparente" te quieras volver para el
programador, mas decisiones tenés que tomar a priori (que muchas veces
no
se
pueden tomar sin conocer la aplicación o el dominio). Sólo la opción de
distribuir objetos por copia o por referencia es un mundo en si mismo.
Saludos,
Andrés
Angel Java Lopez escribió:
Ah! Me olvide de preguntar:
No algo asi ya hecho en Smalltalk, alguna de las 3 opciones de
Guillermo?
Nos leemos!
Angel "Java" Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez
2010/10/8 andres <[email protected]>
Dale, la opción 3 suena piola. El requerimiento sería algo así como:
"Implementar el mensaje #executeAt: anIpAddress port: aPort en
Process
para
que pause la ejecución, se lleve el thread con los objetos en el
scope
a
la
otra imagen y retome la ejecución del punto de partida." Me sumo al
programa
de beta testers para cuando esté listo en un par de días.
Saludos,
Andrés
Guillermo Schwarz escribió:
Primero hay que ponerse de acuerdo en qué tipo de implementación
vamos
a
hacer:
1. Proxy que llame a un objeto remoto que ya existe en el destino
(similar a EJB).
2. Proxy que vaya hasta el servidor y cree una instancia de una
clase
que no existe, para lo cual se requiere que el destino le pregunte
al
gatillador dónde está la definición de la clase, la cargue, la
compile
y
la instancie.
3. ¿Cuál sería el objetivo? ¿Migrar procesos que ya están corriendo?
¿Que corran en el servidor que se indique en duro? ¿Hacer un
balanceador
de carga?
Si los requerimientos no están claros se llegará a un engendro, pero
si
están claros, las decisiones de diseño serán las obvias, podremos
implementar los prototipos, probarlos y no creo que sean más de un
par
de días tenerlo funcionando.
Saludos,
Guillermo.
On Fri, 2010-10-08 at 06:04 +0100, Francisco Garau wrote:
2010/10/8 Guillermo Schwarz <[email protected]>
¿Y tú que parte harías?
¿Probarlo?
;-)
--
Simplex Veri Sigillum
Uy! - si necesitas beta testers avisa, yo
tambien
me prendo
;-)
--
Callarum largo vivurum
--
To post to this group, send email to
[email protected]
To unsubscribe from this group, send email to 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]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[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]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[email protected]<clubsmalltalk%[email protected]>
<clubsmalltalk%[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]>
<clubsmalltalk%[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
--
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
http://www.clubSmalltalk.org
