Quelle est la différence entre les évènements et asynchrone? Entre epoll et AIO?
Event-driven et asynchrones sont souvent utilisés comme synonymes. Existe-il des différences entre les deux?
Aussi, quelle est la différence entre epoll et aio? Comment s'intègrent-ils ensemble?
enfin, j'ai lu plusieurs fois que AIO sous Linux est horriblement cassé. Exactement comment est-il cassé?
Merci.
3 réponses
Events est l'un des paradigmes pour atteindre l'exécution asynchrone. Mais pas tous les systèmes asynchrones. Il s'agit du sens sémantique de ces deux - l'un est la super-entité d'un autre.
epoll et aio utilisent des métaphores différentes:
epoll est une opération de blocage (epoll_wait()) - vous bloquez le thread jusqu'à ce qu'un événement se produise, puis vous envoyez l'événement à différentes procédures/fonctions/branches dans votre code.
dans AIO vous passez l'adresse de vous fonction de rappel (completion routine) au système et le système appelle votre fonction quand quelque chose arrive.
le problème avec AIO est que votre code de fonction de rappel s'exécute à partir du thread système et ainsi de suite en haut de la pile système. Un peu de problème avec cela, comme vous pouvez l'imaginer.
Ils sont des choses complètement différentes.
le paradigme basé sur les événements signifie qu'un objet appelé un "événement" est envoyé au programme chaque fois que quelque chose se produit, sans que ce "quelque chose" doive être interrogé à intervalles réguliers pour découvrir si cela s'est produit. Cet " événement "peut être piégé par le programme pour effectuer certaines actions (c.-à-d. un" handler") -- soit synchrone ou asynchrone.
par conséquent, la gestion des événements peut être synchrone ou asynchrone. JavaScript, par exemple, utilise un système de concours complet synchrone.
asynchrone signifie que des actions peuvent se produire indépendamment du courant d'exécution "principal". Rappelez-vous, il n' signifie "parallèle", ou "thread différent". Une action " asynchrone "peut en fait fonctionner sur le thread principal, bloquant le flux d'exécution" principal " dans l'intervalle. Alors ne confondez pas" asynchrone "avec"multi-threading".
vous pouvez dire que, techniquement parlant, une opération asynchrone automatiquement suppose concours complet -- au moins les événements" complétés"," faulted "ou" avortés/annulés " (un ou plusieurs de ces événements) sont envoyés à l'instigateur de l'opération (ou à L'O/S sous-jacent lui-même) pour signaler que l'opération a cessé. Ainsi, async est toujours dirigée par les événements, mais pas l'inverse.
event driven est un thread simple où les événements sont enregistrés pour un certain scénario. Lorsque ce scénario est affronté, les événements sont déclenchés. Cependant, même à cette époque, chacun des événements sont déclenchés de manière séquentielle. Il n'y a rien d'asynchrone à ce sujet. Nœud.js (webserver) utilise des événements pour traiter des requêtes multiples.
asynchrone est essentiellement multitâche. Il peut engendrer de multiples threads ou processus pour exécuter une certaine fonction. C'est totalement différent de l'événement piloté dans le sens que chaque fil est indépendant et interagit à peine avec le fil principal d'une manière réactive facile. Apache (webserver) utilise plusieurs threads pour traiter les requêtes entrantes.