Hola Mariano, ¿La idea es hacer que los objetos "transparentemente" sean remoteados?
No imagino un caso de uso que realmente requiera eso, sin mencionar que el paper que alguien publicó en el mismo thread de alguien de Sun que dice explícitamente que el sistema se vuelve lento y poco confiable. Por algo los EJBs sólo publican servicios stateless. No tiene sentido hacerlo stateful para que luego el servidor se caiga y que pierdas lo que estabas haciendo. Por otro lado con los EJBs todo es trivial: El remoting, la serialización, etc. La serialización en Smalltalk estaba resuelta el año 1994, cuando conocí Smalltalk. Ahora parece que en Pharo no, pero al menos en GNU Smalltalk sí: http://forum.world.st/ObjectDumper-example-td1293043.html#a1293043 Saludos. Guillermo. On Wed, 2010-10-13 at 00:30 +0200, Mariano Martinez Peck wrote: > Hola angel. Quiero opinar sobre 2 cosas que estoy laburando en mi PhD > y están bastante relacionados. Proxies y serializacion. Uno cree que > son faciles, pero ninguno de los dos es asi. > > Problemas con proxies: > > - Acordate que en ST todo son objetos. Por lo tanto el objeto que vas > a convertir en proxy, puede ser cualquier cosa: Clases, > CompiledMethods, Closures, etc. > > - Cuando en ST nos quedamos sin Object Table, el #become ES LENTO. Se > tiene que traversar todos los objetos de la memoria. Por esto en > Gemstome el become anda mas rapido (tienen object table) > > - Trataste de hacer un unaClase become: MyProxy new ? Cuando luego le > mandas un mensaje a una instancia de unaClase, se rompe todo. > Principalmente porque el proxy es un objeto no una clase (obviemos el > detalle que una clase es un objeto), y la VM para acceder al MethoDict > accede DIRECTAMENTE al offset the las variables. O sea, asume que la > clase tiene X cantidad de variables y que el methodDIct esta en la > posicion X. > > - Muchas veces el doesNotUnderstand: no es suficiente. En varios casos > podes usar el hack de poner el methodDict en nil, e implementar > #cannotInterpret: en la superclase. > > - Lo mismo para los CompiledMethod. Poner un proxy no es igual que > para todo el mundo. Tenes que implementar #run:with:in: y algunos > otros mensajes mas. > > - Hay un montón de mensajes que no van como un bytecode send comun, > sino con bytecodes especiales. Por lo tanto el dnu o cannotInterpret: > pueden ni llamarse. Evalua "ProtoObject class" y vas a que anda..sin > embargo ProtoObject no implementa #class. Y asi como #class hay varios > bytecodes speciales que te cagan. Mira Smalltalk specialSelectors. > > - Tenes que tener mucho cuidado a lo que becomeas con un proxy. Podes > romper todo muy facil. Hay cosas core que no se pueden reemplazar. > > - Debugear es muy dificil porque el mismo debugger manda mensajes para > imprimirlos o cosas asi entonces te los vuelve a traer jjajajaj > > - Si un objecto X tiene como instancia una refencia a un objeto Y, y > haces un become de X a un proxy, el proxy no va a apuntar a Y. POr lo > tanto, si nadie mas estaba apuntando a Y, el GC te llevó a Y. > ImageSegments soluciona esto de una manera muy buena. > > > > Respecto a Serializacion: > > - Es muy dificil hacer un serializador que sea rapido. Acá en mi lab > están haciendo una implementación parecida a Parcels (de VW) y está > andando bien. Pero hay que tener en cuenta un monton de problemas: > > - Ciclos en el subgrafo > > - CompiledMethod, ContextPart (y subclases), Process, Continuations, > etc etc son dificilies de serializar > > - endianess (big or blah) > > - que haces con nil, true, false, etc? y Symbol ? A la hora de > cargarlo en la misma image o en otra, no podes crear duplicados, y los > objetos tienen que apuntar a los ya existentes. Tambien tenes que > hacer un rehash de los sets cuando los traes nuevamente. etc......etc > etc. > > > Bueno, eso nomas. Muchas veces las cosas parecen más faciles no? > > saludos > > Mariano > > > 2010/10/11 Angel Java Lopez <[email protected]> > Hola gente! > > Interesante la discusion del Thread "Blog", pero tambien algo > se fue por las ramas... Cambio de titulo en este mensaje. > > Estuve agregando objetos distribuidos a mi pet project [1], > quedo algo asi: > > http://pastie.org/1213856 > > Tengan encuenta que no tengo libreria de clases de base, asi > que tengo que comenzar desde nil subclass:... ';-) > > Puedo: > > - Levantar un servidor (tecnologia Remoting .NET), en nodo A. > - Levantar un cliente remoto a ese servidor, en nodo B. > - Definir una clase en nodo B. > - Exportar su definicion de B a nodo A. > - Ejecutar desde nodo B algo en nodo A. > - Evaluar en nodo A y devolver el objeto serializado > (contemplando grafos con ciclos, repeticion de objetos, etc..) > a B. > > Me falta evaluar en nodo A y que el resultado quede en A, > viajando a B una especie de proxy, de tal manera que invocando > a ese objeto en B, se ejecute el mensaje en nodo A. > > Mi idea es que si B devuelve un objeto a A, ese resultado > viaja completo. Sino, definiria algo como > > ^host asProxy: result. > > Tendria que escribir post, pero por ahora, tengo esto para > mostrar. > > [1] http://code.google.com/p/ajtalk > > Nos leemos! > > Angel "Java" Lopez > http://www.ajlopez.com > http://twitter.com/ajlopez > > > > > > -- > 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 clubSmalltalk > [email protected] > > http://www.clubSmalltalk.org -- Simplex Veri Sigillum -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
