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.
C'est ça qui me semble rapidement poser problème. Ce qui va pousser à utiliser du C c'est pour être CPU intenssive ou pour t'interfacer avec du matériel ou du code qui ne tourne pas sur beam. Un code de calcul par exemple que tu ne peux ou ne veux pas retoucher pour l'ordonnanceur erlang (et ce n'est pas forcément simple de savoir quand c'est pertinent de se préempter ça peut ruiner les perf). D'où ma question pour la seconde solution. Après c'est questionnable il peut être plus intéressant de vraiment séparer et d'avoir des interactions à coup message queue entre les 2 (pas forcément amqp).
[^] # Re: Comparatif avec d'autres langages orientés "actor model"
Posté par barmic 🦦 . En réponse à la dépêche Sortie d’Erlang/OTP 24. Évalué à 2.
C'est ça qui me semble rapidement poser problème. Ce qui va pousser à utiliser du C c'est pour être CPU intenssive ou pour t'interfacer avec du matériel ou du code qui ne tourne pas sur beam. Un code de calcul par exemple que tu ne peux ou ne veux pas retoucher pour l'ordonnanceur erlang (et ce n'est pas forcément simple de savoir quand c'est pertinent de se préempter ça peut ruiner les perf). D'où ma question pour la seconde solution. Après c'est questionnable il peut être plus intéressant de vraiment séparer et d'avoir des interactions à coup message queue entre les 2 (pas forcément amqp).
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll