Les NIFs sont casse-gueule, oui. Mais on ne parle pas ici de s'interfacer avec des usines à gaz. On parle ici de code très spécifiques qui sera livré "enrobé" avec leur glue erlang.
Un exemple qui me vient en tête serait un calcul sur une grande matrice:
* le code C charge la matrice,
* il fournit quelques point d'entrée pour déclencher un calcul, récupérer son résultat,
* les données de la matrice ne sont pas transférés par message, seules des commandes (charger, calculer, etc) et le résultat.
Pour respecter le scheduler:
* soit le point d'entrée est assuré de ne pas bloquer pour un temps "déraisonnable" par rapport au scheduler;
* soit le point d'entrée risque d'affamer les autres processus, et la librairie erlang pour écrire ces NIFs fournit des primitives pour rendre la main à l'ordonnanceur, qui décidera ou non d'ordonnancer un autre processus.
Si plusieurs instances de ce code doivent s'exécuter, on privilégiera bien sûr de créer des processus erlang qui appelleront le NIF. La parallélisme sera donc géré par erlang et non pas dans le code C.
Au passage, erlang fournit également un mécanisme qui ressemble plus à des RPC pour interagir avec du code dans différents langages (les "ports"):
* le code externe est lancé dans un processus distinct, supervisé par erlang;
* erlang et ce processus échangent des messages comme 2 processus erlang, à travers stdin/out pour le code externe, des librairies dans différents langages (C et Java sont officiellement supportés) fournissent les mécanismes de (de)sérialisation.
La latence est un tout petit peu moins bonne que pour le NIF. En revanche, si le code externe crash, la VM erlang le redémarrera sans aucun problème. Dans le cas d'un NIF, un crash dans le NIF occasionne un crash de la VM.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par Jean Parpaillon . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 3.
Les NIFs sont casse-gueule, oui. Mais on ne parle pas ici de s'interfacer avec des usines à gaz. On parle ici de code très spécifiques qui sera livré "enrobé" avec leur glue erlang.
Un exemple qui me vient en tête serait un calcul sur une grande matrice:
* le code C charge la matrice,
* il fournit quelques point d'entrée pour déclencher un calcul, récupérer son résultat,
* les données de la matrice ne sont pas transférés par message, seules des commandes (charger, calculer, etc) et le résultat.
Pour respecter le scheduler:
* soit le point d'entrée est assuré de ne pas bloquer pour un temps "déraisonnable" par rapport au scheduler;
* soit le point d'entrée risque d'affamer les autres processus, et la librairie erlang pour écrire ces NIFs fournit des primitives pour rendre la main à l'ordonnanceur, qui décidera ou non d'ordonnancer un autre processus.
Si plusieurs instances de ce code doivent s'exécuter, on privilégiera bien sûr de créer des processus erlang qui appelleront le NIF. La parallélisme sera donc géré par erlang et non pas dans le code C.
Au passage, erlang fournit également un mécanisme qui ressemble plus à des RPC pour interagir avec du code dans différents langages (les "ports"):
* le code externe est lancé dans un processus distinct, supervisé par erlang;
* erlang et ce processus échangent des messages comme 2 processus erlang, à travers stdin/out pour le code externe, des librairies dans différents langages (C et Java sont officiellement supportés) fournissent les mécanismes de (de)sérialisation.
La latence est un tout petit peu moins bonne que pour le NIF. En revanche, si le code externe crash, la VM erlang le redémarrera sans aucun problème. Dans le cas d'un NIF, un crash dans le NIF occasionne un crash de la VM.
"Liberté, Sécurité et Responsabilité sont les trois pointes d'un impossible triangle" Isabelle Autissier