J'ai des connaissances très limitées sur Erlang, mais pour autant que je sache, cela peut engendrer des "processus" avec un coût très bas.Quels sont les processus d'Erlang dans les coulisses?
Alors, je me demande, quels sont ces "processus" dans les coulisses?
Sont-ils des fibres? Threads? Continuations?
En outre, à partir de la doc Erlang:
processus Erlang sont légers (grandir et rétrécir dynamique) avec faible encombrement mémoire , rapide pour créer et fin et les frais généraux ordonnancement est faible.
Source: http://www.erlang.org/doc/reference_manual/processes.html
Vous pouvez également jeter un oeil à ceci:
http://www.defmacro.org/ramblings/concurrency.html
Quand on parle de processus Erlang, il est dit:
processus Erlang sont légers fils. Ils sont très bon marché pour commencer et détruire et sont très rapides à basculer entre parce que sous le capot ils sont simplement des fonctions. Un système Erlang typique fonctionnant sur un ordinateur de bureau moderne peut basculer entre plusieurs dizaines de milliers de ces processus. Les processus sont commutés tous les deux douzaine d'appels de fonction, ce qui rend les commutateurs moins granulaires mais enregistre un temps considérable gaspillé en temps normal lors du changement de contexte.
Alors, en quoi cela diffère-t-il des fibres? –
Par exemple, Ruby Fibers ne peut pas fonctionner simultanément sur différents cœurs/processeurs (pour autant que je sache, corrigez-moi si je me trompe), alors qu'Erlang est très bon dans ce domaine. –
N'est-ce pas plus une limitation de Ruby? Vous pouvez créer des fibres à partir de/dans des threads dans win32. et donc il ne devrait pas y avoir de problème pour les faire fonctionner sur plusieurs cœurs? –
Ils sont Lightweight Processes.
Voir aussi ma question Technically why is processes in Erlang more efficient than OS threads.
Fondamentalement, ils sont des threads;) Un espace d'adressage pour eux.
Non, ils ne le sont pas. Les threads sont beaucoup trop lourds pour implémenter les processus d'Erlang. (Je n'ai pas downvote, btw.) –
Donc, ils sont totalement émulés par timesharing un thread? Désolé, cela semble ridiculo9us inefficace dans les moments où les ordinateurs ont plus d'un noyau;) – TomTom
Erlang SMP est un thread par cœur de processeur. La machine virtuelle Erlang fournit à chaque processus un espace d'adresse isolé, une adresse IP et un partage de temps. – cthulahoops
Je n'ai pas trouvé une source définitive, mais d'après ce que je comprends:
Il y a un programmateur (par exemple, ou plusieurs ordonnanceurs qui agissent en collaboration ) qui détermine quel processus Erlang pour lancer sur quel fil OS .
Ces processus ont une pile Growable (peut-être un préambule chacune des fonctions qui attribue pile si nécessaire) afin qu'ils ne consomment pas trop de mémoire à moins qu'ils en ont besoin.
Ils cèdent à l'ordonnanceur selon qu'ils sont en attente sur des données ou ont exécuté pour un laps de temps suffisant (code peut-être préambule dans certaines fonctions vérifie combien de temps écoulé). Contrairement aux discussions, ils ne sont pas préemptés?
Chaque processus alloue de la mémoire à partir de différentes pages ou d'un autre allocateur, donc il est impossible de partager la mémoire (en la même manière que les processus OS évitent le partage de la mémoire).
On peut supposer également avoir Répartiteurs séparés ou pages par processus de Erlang serait également aider à la collecte des ordures, et dans le cas où le processus se termine, alors les pages peuvent être retournés sans avoir à faire une collecte des ordures: http://prog21.dadgum.com/16.html
liés: http://stackoverflow.com/questions/1934707/what-other-systems-beside-erlang-are-based-on-green-processes – jldupont
liés: http://stackoverflow.com/questions/1947180/whats-the-difference-between-green-threads-et-erlangs-processes – jldupont