Question sur plusieurs rappels se produisant en même temps

Question

J'ai un thread qui surveille les événements du système de fichiers sur Mac OS X. Si je copie 100 fichiers dans un dossier qui est regardé, je reçois évidemment plusieurs événements de système de fichiers, et donc plusieurs appels de rappel. Je me demande si ces appels de rappel sont traités les uns après les autres? Ou chaque événement appelle-t-il un thread OS, qui à son tour appelle la fonction de rappel, auquel cas nous aurions plusieurs threads chacun exécutant la même fonction de rappel?

Answer 1

Cela dépend du mécanisme que vous utilisez pour observer les événements du système de fichiers.

Chaque accès à un fichier génère une notification dans un noyau.

Si vous utilisez l'API publique FSEvents, des mises à jour trop fréquentes sont fusionnées en une seule notification. Dans ce cas, la fin de réception est gérée par un run loop, c'est-à-dire que le rappel est et non appelé dans le nouveau thread d'arrière-plan ou le contexte du thread OS. Il est exécuté dans la boucle d'événements que vous avez spécifiée, généralement le thread principal qui exécute la boucle principale de traitement des événements.

Si vous tapez directement sur /dev/fsevents (voir par exemple the OS X book), vous obtenez tous les événements du thread appelant un par un, avec éventuellement plusieurs événements renvoyés par un appel. De même, si vous utilisez plutôt kqueue dérivé de BSD, vous obtiendrez plusieurs événements de l'appel kqueue si les événements sont fréquents.

Dans tous les cas, le système d'exploitation ne fonctionnent pas votre rappel dans un thread nouveau/OS, ni par magie dupliquer votre fil à regarder l'activité du système de fichiers, afin de pouvoir traiter les événements en même temps.