El día 19 de noviembre de 2012 10:39, Angel Java Lopez <[email protected]> escribió: > Me imagino respuestas: > > - No, los Smalltalks X, Y, Z solo manejan un thread, y todo lo demas son > "green threads" > - En el Smalltalk W, hacemos become: multithreading, pero sin controlar nada > (sin poner locks, semaforos o lo que sea) > - En el Smalltalk T, tenemos multithread y hacemos un lindo bolonki para > hacer que el become: sea thread-safe > - En el Smalltalk S, tenemos multithread y la implementacion interna (object > table con celda atomica, con pocos datos; o puntero directo, o lo que sea) > es tal, que el become termina siendo thread-safe por naturaleza > > Cual es?
Habria que ver cual es el soporte de GemStone con respecto al #become:, AFAIR su uso era bastante limitado. En el caso de Dolphin tiene un object-table, y el #become: lo unico que hace es intercambiar pointers de los cuerpos de los objetos receptor y argumento, es una operación muy rápida. El #oneWayBecome: tiene que recorrer toda la object table. Igual cuando haces become, y tu objeto estaba en una hashed collection, y se "convirtió" en un objeto que devuelve un hash distinto empiezan los quilombos :D Yo creo que la "solución" es dartelo sin que sea thread-safe, y hacete cargo :D A los smalltalkers no nos gusta el quilombo :) Saludos! -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] http://www.clubSmalltalk.org
