in Erlang est une façon dont un expéditeur de message peut attendre sur une réponse, il ne continue donc que l'exécution une fois que le message a été traité?
Et je veux dire quelque chose comme ceci: p>
Actor ! DoSomething Continue to this next line of code when DoSomething has been processed
5 Réponses :
Vous pouvez utiliser un recevoir bloc:
http://www.erlang.org/doc/reference_manual/expressions .html # id2270724
lecture de la doc:
recevoir jamais échoue. L'exécution est
suspendu, éventuellement indéfiniment,
jusqu'à ce qu'un message arrive qui fait
correspondre à l'un des modèles et avec un
True Séquence de garde.
En d'autres termes, envoyez un message et attendez une réponse.
J'espère qu'il y a un délai d'attente quelque part ;-)
Cela n'envoie-t-il pas le PID et d'attendre dans une réception? Et cela ne fait-il pas en faire un rappel? Je ne suis pas sûr de moi-même, alors quelqu'un peut vous aider à m'expliquer.
@Zubair: Si tu me dis "Bonjour!" Et vous attendrez le mien "Bonjour!" et je réponds "Bonjour!". Y a-t-il un rappel? C'est comment erlang fonctionne. Juste des processus et des messages. Vous êtes précède, je suis processus. Vous envoyez un message, je envoie un message. Je reçois, vous recevez. Pas de rappel ici.
Ok, merci @hynek. Je suppose que j'ai mal compris quel était un rappel.
Si le processus de réception est un Gen_Server , vous pouvez utiliser Gen_Server: appelez code>. E.G.: gen_server:call(Pid, Message),
% At this point, we know that the other process has answered.
Je suis curieux de savoir combien d'applications du monde réel sont construites avec cette technique.
@jldupont. Vous posez une question valide, je ne suis pas sûr de la réponse. Je dirai cela cependant: si vous construisez un système non trivial sur Erlang, vous devriez probablement utiliser OTP et donc Gen_Server: appelez (). Si vous n'utilisez pas OTP, vous vous retrouverez à réinventer une partie de ce que OTP fait pour vous, ou code de manière à ne pas jouer aux forces d'Erlang ... auquel cas vous devriez probablement utiliser une langue différente en premier lieu.
@IM: Pour être plus précis: je suis curieux de la popularité gen_server: appel () est comparé au Gen_Server: Cast () contrepartie.
Call peut être utilisé pour courir tout type de ressources, contrôlant l'état d'un serveur, demandant des données à partir du serveur, de la réglementation de charge basée sur le serveur, ...
La plus grande chose que Gen_Server: appel a pour pouvoir bloquer l'appelant en retournant immédiatement NORELY tout en préservant le parallélisme de votre côté en accumulant un processus pour gérer l'appel et renvoyer la réponse à partir de là. Essayez de le faire en Java (facilement). Désolé pour le dernier commentaire mais je voulais me sortir moi-même et faire honneur à ce minuscule motif doré erlang (OTP à être juste) me propose gratuitement ...
La première chose à comprendre est que Erlang a été conçu pour traiter le passage des messages asynchrones. En tant que tel, la seule façon d'avoir un message de message synchrone consiste à mettre en place quelque chose qui s'apparente à un accusé de réception.
Imaginez deux processus, P1 et P2. P1 peut exécuter le code suivant: p>
p2() ->
receive
{From, Message} ->
io:format("P2 received message ~p~n",[Message]),
%% processing is done!
From ! {self(), ok}
end.
dépend simplement des situations jldupont. Si un navigateur Web apporte une demande à WebMachine pour une longue ressource Erlang, il n'ya aucun moyen d'utiliser une distribution pour remplir cette demande.
Non, il n'y a que des messages asynchrones qui passent.
Si vous voulez être un peu philosophique, il est très difficile de définir automatiquement lorsqu'un message a été traité. Est-ce que le message est arrivé au processus, a été reçu mais pas encore agi ou à un moment quelconque lorsqu'il a été utilisé par le processus de réception. Il est similaire à obtenir une notification automatique lorsque quelqu'un a "lu" mon courrier. Oui, ils l'ont vu mais ils l'ont vraiment lu?
En d'autres termes, un "envoi de blocage"?
... et pourquoi voudriez-vous cela? Cela ne vaingait-il pas tout le but d'Erlang?
Et quel est le point d'erlang?
Fournir un cadre pour traiter des contraintes d'un système distribué, c'est-à-dire des pertes, des échecs, de l'asynchronisation, du retard, etc.
Pourquoi permettre à un appel de blocage arrêter cela?
@Zubair: Dans un système réel, les défaillances se produisent. L'architecture d'un système doit prendre en compte ce fait. Un "appel de blocage" ne change pas ce fait: alors, pourquoi essayer de canard le problème? Concevoir une architecture où les événements environnementaux sont explicites semble une meilleure approche ... mais encore une fois, c'est une question de goût ;-)
Vous devriez vraiment envisager de lire la documentation et d'expérimenter plutôt que d'inonder Stackoverflow avec tout ce que vous trouvez déroutant. Ceci est couvert dans la documentation des principes de conception OTP. Si vous n'utilisez pas les principes de conception OTP, c'est parce que vous comprenez assez bien Erlang pour ne pas poser de questions comme celle-ci.
Dustin, vous pouvez trouver cela difficile à croire, mais tout le monde n'est pas aussi intelligent que vous. Peut-être que nous avons besoin aussi de smartoverflow.com :)
@Zubair, il ne s'agit pas d'être intelligent. Il s'agit de vous essayer au lieu d'utiliser l'heure d'autre. Presque toutes vos questions sont des choses qui peuvent être googlées en 50 secondes et 10 secondes de processus de pensée. Veuillez cesser d'inonder Stackoverflow avec de telles questions car vous ne voulez pas faire votre travail vous-même.
Votre droit @Glusber. J'ai vérifié votre profil et je vois que vous n'avez pas posé une seule question sur Stackoverflow. Je suppose que je ne peux pas discuter avec quelqu'un qui sait "toutes" les réponses :)
Je ne connais pas toutes les réponses, mais je me soucie du temps d'autres personnes. Je ne le gaspise pas en posant des questions qui peuvent être répondues par moi-même avec une ou deux recherches Google et lire la documentation. Essayez simplement de trouver des réponses plus difficiles vous-même au lieu de vous demander chaque fois que vous rencontrez une plus petite chose de confusion. C'est si facile
Je ne sais pas quoi dire. Je fais Google et tente de rechercher les réponses. Je suppose que vous êtes bien cependant, mais vous devez vous rappeler que je ne suis pas un gars de type technicien, alors les choses que vous pouvez comprendre de la documentation en ligne sont totales Gibberish à 99,99% de la population et, malheureusement, je suis l'une de ces 99,99%. Je sais que Stackoverflow n'a que 6 millions de membres, et peut-être qu'ils sont dans ce top 00.01% et sont tous des techniciens. Peut-être que je suis la mauvaise démographie pour ce site. Mais je demanderais aussi, y a-t-il un site pour quelqu'un comme moi, qui est beaucoup moins technique que vous-même?
Désolé d'être un peu trop dur. J'ai supposé que vous êtes un développeur et c'était la raison de mes critiques. Je suppose que la meilleure façon pour la personne de non-technologie d'apprendre sur Erlang est de lire un livre à ce sujet. Je suggère "Programmer Erlang" de Joe Armstrong. Encore pardon
Pas de problème @bilber. Je viens de me commander une copie. Merci :)