les canaux de blocage contre un message asynchrone passage

Question

Je l'ai remarqué deux méthodes pour « le passage de messages ». Je l'ai vu un usage Erlang et l'autre est de Stackless Python. D'après ce que je comprends la différence est ici

Erlang Style - les messages sont envoyés et en file d'attente dans la boîte aux lettres du processus de réception. De là, ils sont éliminés dans une base FIFO. Une fois que le premier processus envoie le message qu'il est libre de continuer.

Style Python - Processus de files d'attente A jusqu'à envoyer à traiter B. B effectue actuellement une autre action, si A est gelée jusqu'à ce que B est prêt à recevoir. Une fois que B ouvre un canal de lecture, A envoie les données, ils continuent tous deux.

Maintenant, je vois les avantages de la méthode Erlang étant que vous n'avez pas encore les processus bloqués. Si B ne peut recevoir, A peut encore continuer. Cependant, je l'ai remarqué dans certains programmes que je l'ai écrit, qu'il est possible pour les boîtes de message Erlang pour obtenir plein de centaines (ou des milliers) de messages depuis l'afflux de messages est supérieure à la sortie.

Maintenant, je n'ai pas écrit un grand programme dans les deux cadre / langue pour que je me demande vos expériences sont avec cela, et si elle est quelque chose que je devrais même inquiéter.

Oui, je sais que cela est abstrait, mais je suis aussi à la recherche des réponses plutôt abstraites.

Answer 1

Mon expérience dans la programmation Erlang est que lorsque vous vous attendez à un taux de messagerie élevé (qui est un producteur plus rapide que le consommateur), vous ajoutez votre propre contrôle de flux. Un scénario simple

• le consommateur: envoyer un message, attendez ack, puis répéter.
• Le producteur: attendre un message, envoyez un message ack lorsque reçu et traité, puis répétez
.

On peut aussi inverser, les attend à la production pour le consommateur à venir et de saisir les N prochains messages disponibles.

Ces approches et autres contrôle de flux peuvent être cachés derrière les fonctions, le premier est le plus souvent déjà disponible en gen_server:call/2,3 contre un processus de comportement gen_server OTP.

Je vois la messagerie asynchrone en Erlang comme meilleure approche, car quand latences sont élevés, vous pourriez très bien voulez éviter une synchronisation lorsque la messagerie entre les ordinateurs. On peut alors composer des moyens astucieux pour mettre en œuvre le contrôle de flux. Dites, ce qui nécessite un ack du consommateur pour tous les messages N le producteur ont envoyé, ou envoyer un spécial « ping moi quand vous avez reçu ce un » message maintenant et puis, à compter le temps de ping.

Answer 2

D'une manière générale, c'est des files d'attente sans bornes contre les files d'attente bornés. Un canal de stackless peut être considéré comme un cas particulier d'une file d'attente avec 0 taille.

files d'attente bornées ont tendance à une impasse. Deux fils / processus en essayant d'envoyer un message à l'autre, à la fois avec une file d'attente complète.

files d'attente Unbounded ont échec plus subtile. Une grande boîte aux lettres ne répondra pas aux exigences de latence, comme vous l'avez mentionné. Allez assez loin et il finira par déborder; pas une telle chose que la mémoire infinie, il est vraiment juste une file d'attente avec une énorme limitée limite qui avorte le processus quand il est plein.

Quel est le meilleur? C'est difficile à dire. Il n'y a pas de réponse facile ici.