2012/10/31 Esteban A. Maringolo <[email protected]> > El día 30 de octubre de 2012 18:16, Guillermo Schwarz > <[email protected]> escribió: > > Hasta donde sé para el caso de Smalltalk, todo es asíncrono. De hecho > para > > hacer que no sea asíncrono hay que hacer algún tipo de esfuerzo. > > No, no es asincrónico, a menos que exista un fork en el medio, y la > concurrencia se maneja con semáforos y mutexes. > > > Por ejemplo para ejecutar un ciclo: > > [ condicion ] whileTrue: [ bloque ]. > > > El bloque por lo tanto se ejecuta de manera asíncrona (en la práctica > cada > > ejecución del bloque no es asíncrona, pero podría hacerse asíncronamente > sin > > ningún problema). > > Entonces siempre es, y a la vez podría hacerse sin ningun problema? > Alguna de las dos partes no es correcta. Si es no hay nada que deba > hacerse para que siga siendo. >
El tema está en que Smalltalk se basa en el modelo funcional (según Alan Kay se inspiró en Lisp). La programación funcional tiene la ventaja de que no modifica los objetos que se pasan como parámetro. En otras palabras, si pasas objetos como parámetro y no los modificas, entonces puedes tener varios threads simultáneos que al trabajar sobre objetos diferentes (o copias de ellos o bien referencias a objetos inmutables), podría hacerse un Smalltalk con varios threads paralelos. En particular no hay motivo para pensar que los objetos en Smalltalk son compartidos. Ese es justamente el modelo usado en J2EE con los EJBs para lograr escalabilidad, pero puede ser aún mucho más liviano si los objetos automáticamente se tratan como objetos transientes (creados en el momento de un request y desechados inmediatamente). Los únicos objetos que no tienen esa propiedad son las clases y aquellos objetos básicos que sirvan para estructurar el runtime (como el ejemplo de SystemDictionary Smalltalk). > > > Luego puedes hacer que todas las operaciones se vuelvan > > asíncronas de la misma manera que se hacía con WinSocks en Smalltalk > > Express. Simplemente entregas un bloque como parámetro cuando el > subsistema > > está listo para escribir un socket o leerlo. Lo mismo se puede hacer para > > leer y escribir archivos, conversar con BD, etc. > > Sí, en lo que es sockets y algunas implementaciones de drivers de BD > se usa mucho la de pasar un block como callback. > No hay implementación para file I/O que trabaje de esa manera. > Es trivial hacerla. Haces un objeto proxy que simplemente cree una cola y encole los mensajes. La cola va a parar a otro thread que contiene el objeto que realiza las operaciones reales de manera secuencial. Esa pŕáctica permite que todas las operaciones sean asíncronas, con la salvedad de que debes saber qué ejecutar cuando termine la operación, por ejemplo, si hago una operación de lectura a la BD, debo hacer algo con el resultado, ese resultado lo pones en un bloque (también conocido como callback). ¿Se entiende? > > Quizas wrappeando libuv (https://github.com/joyent/libuv) pueda > obtenerse esa funcionalidad, sin tener que tocar la VM. > Ok, algo parecido. Lo que yo digo es que con Smalltalk no necesitas modificar la VM ya que todos los mecanismos pueden ser implementados de manera realtivamente simple encima de lo que ya existe. > > > Quiźas es la mayor problema de Smalltalk es que se asume que todos los > > objetos no ejecutan en paralelo, ya que hay un sólo thread en todo el > > sistema. Coo lo resuelve Lisp es decir: no hay objetos globales. En > > Smalltalk todas las clases son globales y algunos objetos como el > > SystemDictionary Smalltalk tendrían que ser "synchronized". > > Aca no te entendí, no entiendo del todo en que afecta el asincronismo a > eso. > La concurrencia es una cosa, y el asincronismo otra, que puedan darse > ambas. OK. Paralelismo nadie necesita, pero es útil. Si puedes hacer algo en un thread, hacer lo mismo en 10^6 threads es mejor. Por lo menos si tenemos un sitio web, parece ser útil, ¿no? En el caso de la asincronía, es necesaria para hacer lo mismo que node.js, que cada operación se resuelva lo más rápido posible. Esto es porque las operaciones de IO son increíblemente lentas, de modo que si la CPU puede seguir ejecutando algo, como pedir más operaciones de IO, entonces puedes acelerar el thread muchísimo. Como expliqué un poco antes, los threads sirven para implementar asincronía mediante proxies, colas y callbacks (bloques), que es justamente lo que hace node.js. Node no soluciona los conflictos de la concurrencia, > simplemente permite que haya más clientes de manera concurrente > haciendo que las tareas no sean bloqueantes (o lo sean lo menos > posible). > > Saludos. > > Esteban A. Maringolo > > -- > 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
