|
Lo que dices es valedero para la implementacion tradicional. Pero el punto es que la forma de afrontar este problema es fundamentalmente erroneo.
Por eso es bueno leer el articulo del porque ErlLang toma una ruta diferente.
Ya que no se comparte la memoria, se parece a un modelo de procesos y de hecho asi se denomina en ErLang, sin embargo no son procesos tal como se define en los OS, es mas bien un sistema de hilos diferentes. La informacion de desempeño de ErlLang atestigua que es un esquema muchisimo mas escalable y que consume menores recursos...
El segundo problema... no lo es. Los bloqueos es una forma compleja de resolver los problemas, pero no es la unica. Por ejemplo, Windows permite enviar mensajes (y asi se implementan los click, click derecho, movimientos del mouse, e infinidad de cosas) y de paso usar este mecanismo es algo que he visto como recomendado. Usando el sistema de mensajes de Windows junto con threads es una forma que resuelve muchas dificultades.
El que tenga estas caracteristicas es lo que lo haria aun *mas* usable.
La experiencia muestra que casi todo el mundo logra captar como programar en ambientes sin-estado como en paginas web, en contraste, casi nadie hace programacion multi-hilos/procesos porque es muy complejo.
Y sinceramente, no se me ocurre como este esquema no podria aplicarse en los casos donde multicore/hilos es util, quizas lo unico es que la informacion hay que serializarla y deserealizarla como ocurre en un sitio web o con servicios web, pero en la practica no es un problema tan duro de resolver frente al problema de base que es la aplicacion de funciones paralerizables.
|