El 24 de abril de 2014, 1:00, Jesus Cea <[email protected]> escribió: > On 31/12/13 16:44, Chema Cortes wrote: > > Para peticiones asíncronas, el patrón que parece funcionar mejor es el > > patrón "Actor". Al convesar con el resto de actores a través de > > mensajes, es mucho más fácil desacoplar y testear cada parte por > > separado (o sea, con "mocks" que emulan otros actores). Lo único > > complicado es crear un diseño de actores que sea suficientemente > > resiliente (recuperación frente a fallos). Para python hay librerías > > Actor como pykka[1], parley[2] o pulsar[3], pero no las he probado > > como para darte alguna idea. > > > > Para realizar las pruebas, mírate pywovs[4] a ver si te ahorra trabajo. > > > > [1]: http://pykka.readthedocs.org/en/latest/ > > [2]: http://osl.cs.uiuc.edu/parley/ > > [3]: http://pythonhosted.org/pulsar/ > > > > [4]: http://heynemann.github.io/pyvows/ > > > > > > No conozco libros que traten de estos temas para python. Mi consejo es > > que te mires otros lenguajes como Scala/Akka o Erlang si piensas hacer > > un sistema de actores algo más complejo. > > Cuando vi por ahí el tema de actores, hace ya bastantes años, me > sorprendí que fuera una novedad, porque yo es lo que suelo usar hace > mucho, cuando me dejan. Mis primeros pinitos con algo parecido fue con > la idea de "tablón de anuncios" del lenguaje Linda. Escalabilidad > infinita, reparto de carga automática, transparencia ante caídas de todo > lo que no sea el propio "tablón de anuncios".... > > https://en.wikipedia.org/wiki/Linda_%28coordination_language%29 > > Muerto hace mucho: https://code.google.com/p/pylinda/ > > Me apunto las librerías de actores que indicas. Las curiosearé. >
Nunca hay que sorprenderse que las buenas ideas vuelvan mejoradas. No sé si usarás un modelo Linda en tu "tablón de anuncios", pero este modelo no es precisamente de *"escabilidad infinita"*. Era su punto flaco, que al crecer el número de procesos el sincronismo del tuple-space ralentizaba bastante y hacía perder disponibilidad. En general, estamos ante un principio de incertidumbre de la programación concurrente: nunca podrás tener un sistema consistente y disponible a la vez ([Teorema CAP][1]). Al igual que pasa en física al cambiar de escala, esta incertidumbre se hace más patente al aumentar el número de particiones (+40000). A pequeña escala se nota menos. La novedad del modelo actor está en poder crear sistemas masivamente concurrentes que sean resilientes (["Manifiesto Reactivo"][2]). Porque fallar, seguro que van a fallar. Actuálmente, es un tema en el que se está investigando mucho y nunca se sabe qué viejas/nuevas ideas surgirán estos años. [1]: http://es.wikipedia.org/wiki/Teorema_CAP [2]: http://www.reactivemanifesto.com > > -- > Jesús Cea Avión _/_/ _/_/_/ _/_/_/ > [email protected] - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ > jabber / xmpp:[email protected] _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > > > _______________________________________________ > Python-es mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ > > -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://ch3m4.org/blog Buscador Python Hispano: http://ch3m4.org/python-es
_______________________________________________ Python-es mailing list [email protected] https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
