perkamon - en to fr translation catalogue (76 entries)

note: type: TH
en: 2023-05-03
fr: 3 mai 2023

note: type: TH
en: Linux man-pages 6.05.01
fr: Pages du manuel de Linux 6.05.01

note: type: SH
en: NAME
fr: NOM

note: type: Plain text
en: epoll - I/O event notification facility
fr: epoll – Notifications d'événements d'entrées et sorties

note: type: Plain text
en: The B<epoll> API performs a similar task to B<poll>(2): monitoring multiple file descriptors to see if I/O is possible on any of them.  The B<epoll> API can be used either as an edge-triggered or a level-triggered interface and scales well to large numbers of watched file descriptors.
fr: L'interface de programmation (API) B<epoll> réalise une tâche similaire à B<poll>(2) : surveiller plusieurs descripteurs de fichier pour voir si des E/S y sont possibles. L'API B<epoll> peut être déclenchée par changement de niveau ou par changement d'état et s'adapte bien à un grand nombre de descripteurs surveillés.

note: type: Plain text
en: The central concept of the B<epoll> API is the B<epoll> I<instance>, an in-kernel data structure which, from a user-space perspective, can be considered as a container for two lists:
fr: Le concept central de l’API B<epoll> est l’I<instance> d’B<epoll>, une structure interne au noyau qui, du point de vue espace utilisateur, peut être considérée comme un conteneur pour deux listes :

note: type: IP
en: \[bu]
fr: -

note: type: Plain text
en: The I<interest> list (sometimes also called the B<epoll> set): the set of file descriptors that the process has registered an interest in monitoring.
fr: La liste I<interest> (parfois appelée l’ensemble B<epoll>) : l’ensemble des descripteurs de fichier que le processus a enregistrés comme intéressants à surveiller.

note: type: Plain text
en: The I<ready> list: the set of file descriptors that are "ready" for I/O.  The ready list is a subset of (or, more precisely, a set of references to)  the file descriptors in the interest list.  The ready list is dynamically populated by the kernel as a result of I/O activity on those file descriptors.
fr: La liste I<ready> : l’ensemble des descripteurs de fichier prêts (ready) pour des E/S. Cette liste est un sous-ensemble de (plus précisément, un ensemble de références de) descripteurs de fichier de la liste I<interest>.  La liste I<ready> est alimentée dynamiquement par le noyau selon le résultat des activités d’E/S de ces descripteurs de fichier.

note: type: Plain text
en: The following system calls are provided to create and manage an B<epoll> instance:
fr: Les appels système suivants sont fournis pour créer et gérer une instance d’B<epoll> :

note: type: Plain text
en: B<epoll_create>(2)  creates a new B<epoll> instance and returns a file descriptor referring to that instance.  (The more recent B<epoll_create1>(2)  extends the functionality of B<epoll_create>(2).)
fr: B<epoll_create>(2) crée une instance d’B<epoll> et renvoie un descripteur de fichier référençant cette instance. La version plus récente d'B<epoll_create1>(2) étend les fonctionnalités d'B<epoll_create>(2).

note: type: Plain text
en: Interest in particular file descriptors is then registered via B<epoll_ctl>(2), which adds items to the interest list of the B<epoll> instance.
fr: L'intérêt pour des descripteurs de fichier particuliers est ensuite enregistré avec B<epoll_ctl>(2), qui ajoute les articles dans la liste I<interest> de l’instance d’B<epoll>.

note: type: Plain text
en: B<epoll_wait>(2)  waits for I/O events, blocking the calling thread if no events are currently available.  (This system call can be thought of as fetching items from the ready list of the B<epoll> instance.)
fr: B<epoll_wait>(2) attend les événements d'E/S, en bloquant le thread appelant si aucun événement n'est actuellement disponible. Cet appel système peut être considéré comme recherchant des articles dans la liste I<ready> de l’instance d’B<epoll>.

note: type: SS
en: Level-triggered and edge-triggered
fr: Détection par changement de niveau ou d’état

note: type: Plain text
en: The B<epoll> event distribution interface is able to behave both as edge-triggered (ET) and as level-triggered (LT).  The difference between the two mechanisms can be described as follows.  Suppose that this scenario happens:
fr: L'interface de distribution d'événements d’B<epoll> est capable de se comporter en détection de changement de niveau (Level Triggered — LT) ou d’état (Edge Triggered — ET). La différence entre ces deux mécanismes est décrite ci-dessous. Supposons que le scénario suivant se produise\ :

note: type: Plain text
en: The file descriptor that represents the read side of a pipe (I<rfd>)  is registered on the B<epoll> instance.
fr: Le descripteur de fichier qui représente le côté lecture d'un tube (I<rfd>) est enregistré dans l'instance d’B<epoll>.

note: type: Plain text
en: A pipe writer writes 2\ kB of data on the write side of the pipe.
fr: Une écriture dans le tube envoie 2\ Ko de données du côté écriture du tube.

note: type: Plain text
en: A call to B<epoll_wait>(2)  is done that will return I<rfd> as a ready file descriptor.
fr: Un appel à B<epoll_wait>(2) est effectué et renvoie I<rfd> comme descripteur de fichier prêt.

note: type: Plain text
en: The pipe reader reads 1\ kB of data from I<rfd>.
fr: Un lecteur du tube lit 1\ Ko de données depuis I<rfd>.

note: type: Plain text
en: A call to B<epoll_wait>(2)  is done.
fr: Un appel d’B<epoll_wait>(2) est effectué.

note: type: Plain text
en: If the I<rfd> file descriptor has been added to the B<epoll> interface using the B<EPOLLET> (edge-triggered)  flag, the call to B<epoll_wait>(2)  done in step B<5> will probably hang despite the available data still present in the file input buffer; meanwhile the remote peer might be expecting a response based on the data it already sent.  The reason for this is that edge-triggered mode delivers events only when changes occur on the monitored file descriptor.  So, in step B<5> the caller might end up waiting for some data that is already present inside the input buffer.  In the above example, an event on I<rfd> will be generated because of the write done in B<2> and the event is consumed in B<3>.  Since the read operation done in B<4> does not consume the whole buffer data, the call to B<epoll_wait>(2)  done in step B<5> might block indefinitely.
fr: Si le descripteur I<rfd> a été ajouté à l'ensemble B<epoll> en utilisant l'attribut B<EPOLLET> (détection de changement d'état), l'appel B<epoll_wait>(2), réalisé à l'étape B<5>, va probablement bloquer bien qu'il y ait des données toujours présentes dans le tampon d'entrée du fichier tandis que le pair distant attendra une réponse basée sur les données qu'il a déjà envoyées. La raison en est que le mécanisme de distribution d'événements détectés par changement d’état délivre les événements seulement lorsque des événements surviennent dans le descripteur de fichier supervisé. Ainsi, à l'étape B<5>, l'appelant peut attendre des données qui sont déjà présentes dans le tampon d'entrée. Dans l'exemple ci-dessus, un événement sur I<rfd> sera déclenché à cause de l'écriture à l'étape B<2> et l'événement est consommé dans l’étape B<3>. Comme l'opération de lecture de l'étape B<4> ne consomme pas toutes les données du tampon, l'appel à B<epoll_wait>(2) effectué à l'étape B<5> peut verrouiller indéfiniment.

note: type: Plain text
en: An application that employs the B<EPOLLET> flag should use nonblocking file descriptors to avoid having a blocking read or write starve a task that is handling multiple file descriptors.  The suggested way to use B<epoll> as an edge-triggered (B<EPOLLET>)  interface is as follows:
fr: Une application qui emploie l'attribut B<EPOLLET> de la fonction B<epoll> devrait toujours utiliser des descripteurs non bloquants pour éviter qu'une lecture ou une écriture affame une tâche qui gère plusieurs descripteurs de fichier. L'utilisation préconisée d'B<epoll> comme interface en détection par changement d’état (B<EPOLLET>) est la suivante :

note: type: Plain text
en: with nonblocking file descriptors; and
fr: avec des descripteurs non bloquants\ ;

note: type: Plain text
en: by waiting for an event only after B<read>(2)  or B<write>(2)  return B<EAGAIN>.
fr: en attente d’évènement seulement après qu'un B<read>(2) ou un B<write>(2) ait renvoyé B<EAGAIN>.

note: type: Plain text
en: By contrast, when used as a level-triggered interface (the default, when B<EPOLLET> is not specified), B<epoll> is simply a faster B<poll>(2), and can be used wherever the latter is used since it shares the same semantics.
fr: En revanche, lorsqu'il est utilisé avec l'interface en détection par changement de niveau (par défaut si B<EPOLLET> n'est pas spécifié), B<epoll> est une alternative plus rapide à B<poll>(2) et peut être employé à chaque fois que ce dernier est utilisé, car il utilise la même sémantique.

note: type: Plain text
en: Since even with edge-triggered B<epoll>, multiple events can be generated upon receipt of multiple chunks of data, the caller has the option to specify the B<EPOLLONESHOT> flag, to tell B<epoll> to disable the associated file descriptor after the receipt of an event with B<epoll_wait>(2).  When the B<EPOLLONESHOT> flag is specified, it is the caller's responsibility to rearm the file descriptor using B<epoll_ctl>(2)  with B<EPOLL_CTL_MOD>.
fr: Puisque même dans un B<epoll> de type détection le changement d'état, plusieurs événements peuvent être générés à la réception de nombreux blocs de données, l'appelant peut, en spécifiant l'attribut B<EPOLLONESHOT>, faire désactiver par B<epoll> le descripteur de fichier associé après la réception d'un événement avec B<epoll_wait>(2). Lorsque l'attribut B<EPOLLONESHOT> est spécifié, il est de la responsabilité de l'appelant de réarmer le descripteur en utilisant B<epoll_ctl>(2) avec B<EPOLL_CTL_MOD>.

note: type: Plain text
en: If multiple threads (or processes, if child processes have inherited the B<epoll> file descriptor across B<fork>(2))  are blocked in B<epoll_wait>(2)  waiting on the same epoll file descriptor and a file descriptor in the interest list that is marked for edge-triggered (B<EPOLLET>)  notification becomes ready, just one of the threads (or processes) is awoken from B<epoll_wait>(2).  This provides a useful optimization for avoiding "thundering herd" wake-ups in some scenarios.
fr: Si plusieurs threads (ou processus si les processus enfant ont hérité du descripteur de fichier d’B<epoll> à travers B<fork>(2)) sont bloqués dans B<epoll_wait>(2) en attente du même descripteur de fichier d’B<epoll> et qu’un descripteur de fichier dans la liste I<interest>, qui est marqué pour une notification par détection de changement d'état (B<EPOLLET>), devienne prêt, seul un des threads (ou processus) est réveillé de B<epoll_wait>(2). Cela fournit une optimisation utile pour éviter la bousculade de réveils (thundering herd) dans certain scénarios.

note: type: SS
en: Interaction with autosleep
fr: Interaction avec autosleep

note: type: Plain text
en: If the system is in B<autosleep> mode via I</sys/power/autosleep> and an event happens which wakes the device from sleep, the device driver will keep the device awake only until that event is queued.  To keep the device awake until the event has been processed, it is necessary to use the B<epoll_ctl>(2)  B<EPOLLWAKEUP> flag.
fr: Si le système est en mode B<autosleep> à l’aide de I</sys/power/autosleep> et qu’un événement survient et sort le périphérique de sa veille, le pilote de périphérique ne gardera le périphérique actif que jusqu’à la mise en file d’attente de l’événement. Pour garder le périphérique actif jusqu’au traitement de l’événement, l’attribut B<EPOLLWAKEUP> d’B<epoll_ctl>(2) doit être utilisé.

note: type: Plain text
en: When the B<EPOLLWAKEUP> flag is set in the B<events> field for a I<struct epoll_event>, the system will be kept awake from the moment the event is queued, through the B<epoll_wait>(2)  call which returns the event until the subsequent B<epoll_wait>(2)  call.  If the event should keep the system awake beyond that time, then a separate I<wake_lock> should be taken before the second B<epoll_wait>(2)  call.
fr: Quand l’attribut B<EPOLLWAKEUP> est défini dans le champ B<events> pour une I<struct epoll_event>, le système sera gardé actif à partir du moment où l’événement est mis en file d’attente, à l’aide de l’appel B<epoll_wait>(2) qui renvoie l’événement jusqu’à l’appel B<epoll_wait>(2) suivant. Si l’événement doit garder le système actif au delà de ce moment, alors un I<wake_lock> séparé devrait être pris avant le second appel à B<epoll_wait>(2).

note: type: SS
en: /proc interfaces
fr: Interfaces /proc

note: Following was added in Linux 2.6.28, but them removed in Linux 2.6.29 .TP .IR /proc/sys/fs/epoll/max_user_instances " (since Linux 2.6.28)" This specifies an upper limit on the number of epoll instances that can be created per real user ID. type: Plain text
en: The following interfaces can be used to limit the amount of kernel memory consumed by epoll:
fr: Les interfaces suivantes peuvent être utilisées pour limiter la quantité de mémoire du noyau utilisée par B<epoll>\ :

note: type: TP
en: I</proc/sys/fs/epoll/max_user_watches> (since Linux 2.6.28)
fr: I</proc/sys/fs/epoll/max_user_watches> (depuis Linux 2.6.28)

note: Linux 2.6.29 (in Linux 2.6.28, the default was 1/32 of lowmem) type: Plain text
en: This specifies a limit on the total number of file descriptors that a user can register across all epoll instances on the system.  The limit is per real user ID.  Each registered file descriptor costs roughly 90 bytes on a 32-bit kernel, and roughly 160 bytes on a 64-bit kernel.  Currently, the default value for I<max_user_watches> is 1/25 (4%) of the available low memory, divided by the registration cost in bytes.
fr: Cela définit une limite au nombre total de descripteurs de fichiers qu'un utilisateur peut enregistrer au travers de toutes les instances d’B<epoll> du système. La limite est imposée par identifiant d'utilisateur réel. Chaque descripteur de fichier enregistré coûte environ 90 octets sur un noyau 32 bits et environ 160 octets sur un noyau 64 bits. Actuellement la valeur par défaut pour I<max_user_watches> est de 1/25 (4%) de la mémoire basse disponible, divisé par le coût d'allocation en octets.

note: type: SS
en: Example for suggested usage
fr: Exemple d'utilisation

note: type: Plain text
en: While the usage of B<epoll> when employed as a level-triggered interface does have the same semantics as B<poll>(2), the edge-triggered usage requires more clarification to avoid stalls in the application event loop.  In this example, listener is a nonblocking socket on which B<listen>(2)  has been called.  The function I<do_use_fd()> uses the new ready file descriptor until B<EAGAIN> is returned by either B<read>(2)  or B<write>(2).  An event-driven state machine application should, after having received B<EAGAIN>, record its current state so that at the next call to I<do_use_fd()> it will continue to B<read>(2)  or B<write>(2)  from where it stopped before.
fr: Tandis que l'utilisation d’B<epoll> avec un déclenchement par changement de niveau correspond à la même sémantique que B<poll>(2), le déclenchement par changement d'état nécessite plus de clarification pour éviter des décrochages dans la boucle d’évènements de l’application. Dans cet exemple, l’écouteur emploie un socket non bloquant sur lequel B<listen>(2) a été appelé. La fonction I<do_use_fd()> va utiliser le nouveau descripteur de fichier jusqu'à ce qu’B<EAGAIN> soit renvoyé par B<read>(2) ou par B<write>(2). Une application d’automate fini piloté par les évènements devrait, après réception d'B<EAGAIN>, enregistrer l'état en cours, afin que lors de l’appel suivant à I<do_use_fd()>, elle continue avec le B<read>(2) ou le B<write>(2) là où elle s'est arrêtée.

note: type: Plain text
en: When used as an edge-triggered interface, for performance reasons, it is possible to add the file descriptor inside the B<epoll> interface (B<EPOLL_CTL_ADD>)  once by specifying (B<EPOLLIN>|B<EPOLLOUT>).  This allows you to avoid continuously switching between B<EPOLLIN> and B<EPOLLOUT> calling B<epoll_ctl>(2)  with B<EPOLL_CTL_MOD>.
fr: Lorsqu'on utilise une détection de changement d'états, pour des raisons de performances, il est possible d'ajouter le descripteur de fichier dans l'interface d’B<epoll> (B<EPOLL_CTL_ADD>) après, en spécifiant (B<EPOLLIN>|B<EPOLLOUT>). Cela évite de basculer sans cesse entre B<EPOLLIN> et B<EPOLLOUT> lors des appels B<epoll_ctl>(2) avec B<EPOLL_CTL_MOD>.

note: type: SS
en: Questions and answers
fr: Questions/Réponses

note: type: Plain text
en: What is the key used to distinguish the file descriptors registered in an interest list?
fr: Quelle est la clé utilisée pour distinguer les descripteurs de fichier enregistrés dans une liste I<interest> ?

note: type: Plain text
en: The key is the combination of the file descriptor number and the open file description (also known as an "open file handle", the kernel's internal representation of an open file).
fr: La clé est une combinaison du numéro du descripteur de fichier et de la description du fichier ouvert (aussi connue comme « open file handle », la représentation interne au noyau d'un fichier ouvert).

note: type: Plain text
en: What happens if you register the same file descriptor on an B<epoll> instance twice?
fr: Que se passe-t-il si on enregistre deux fois le même descripteur de fichier dans une instance d’B<epoll>\ ?

note: But a file descriptor duplicated by fork(2) can't be added to the set, because the [file *, fd] pair is already in the epoll set. That is a somewhat ugly inconsistency.  On the one hand, a child process cannot add the duplicate file descriptor to the epoll set.  (In every other case that I can think
en: You will probably get B<EEXIST>.  However, it is possible to add a duplicate (B<dup>(2), B<dup2>(2), B<fcntl>(2)  B<F_DUPFD>)  file descriptor to the same B<epoll> instance.  This can be a useful technique for filtering events, if the duplicate file descriptors are registered with different I<events> masks.
fr: Vous aurez probablement un B<EEXIST>. Cependant il est possible d'ajouter un duplicata de descripteur (B<dup>(2), B<dup2>(2), B<F_DUPFD> de B<fcntl>(2)) sur la même instance d’B<epoll>. Cela peut être une technique utile pour le filtrage d'événements, si les descripteurs dupliqués sont enregistrés avec des masques I<events> différents.

note: type: Plain text
en: Can two B<epoll> instances wait for the same file descriptor? If so, are events reported to both B<epoll> file descriptors?
fr: Deux instances d’B<epoll> peuvent-elles attendre le même descripteur de fichier\ ? Si oui, les événements seront-ils reportés sur les deux descripteurs de fichier d’B<epoll>\ ?

note: type: Plain text
en: Yes, and events would be reported to both.  However, careful programming may be needed to do this correctly.
fr: Oui, et les événements seront rapportés aux deux. Toutefois, une programmation soignée est nécessaire pour que cela soit fait correctement.

note: type: Plain text
en: Is the B<epoll> file descriptor itself poll/epoll/selectable?
fr: Est-ce que le descripteur d’B<epoll> lui-même est sujet à poll/epoll/select\ ?

note: type: Plain text
en: Yes.  If an B<epoll> file descriptor has events waiting, then it will indicate as being readable.
fr: Oui. Si un descripteur de fichier d’B<epoll> a des événements en attente, alors il indiquera qu'il est lisible.

note: type: Plain text
en: What happens if one attempts to put an B<epoll> file descriptor into its own file descriptor set?
fr: Que se passe-t-il si on cherche à placer un descripteur d’B<epoll> dans son propre ensemble de descripteurs de fichier \ ?

note: type: Plain text
en: The B<epoll_ctl>(2)  call fails (B<EINVAL>).  However, you can add an B<epoll> file descriptor inside another B<epoll> file descriptor set.
fr: L'appel B<epoll_ctl>(2) échouera (B<EINVAL>). Toutefois vous pouvez ajouter un descripteur d’B<epoll> dans un autre ensemble de descripteurs de fichier d’B<epoll>.

note: type: Plain text
en: Can I send an B<epoll> file descriptor over a UNIX domain socket to another process?
fr: Puis-je envoyer le descripteur d’B<epoll> à travers un socket UNIX vers un autre processus\ ?

note: type: Plain text
en: Yes, but it does not make sense to do this, since the receiving process would not have copies of the file descriptors in the interest list.
fr: Oui, mais il n'y a aucune raison de faire ça, puisque le processus récepteur n'aura pas de copie des descripteurs de fichier de la liste I<interest>.

note: type: Plain text
en: Will closing a file descriptor cause it to be removed from all B<epoll> interest lists?
fr: Est-ce que la fermeture d'un descripteur le supprime automatiquement de toutes les listes I<interest> d’B<epoll>\ ?

note: type: Plain text
en: Yes, but be aware of the following point.  A file descriptor is a reference to an open file description (see B<open>(2)).  Whenever a file descriptor is duplicated via B<dup>(2), B<dup2>(2), B<fcntl>(2)  B<F_DUPFD>, or B<fork>(2), a new file descriptor referring to the same open file description is created.  An open file description continues to exist until all file descriptors referring to it have been closed.
fr: Oui, mais prenez note des points suivants. Un descripteur de fichier est une référence vers la description d'un fichier ouvert (consultez B<open>(2)). À chaque fois qu'un descripteur est dupliqué avec B<dup>(2), B<dup2>(2), B<F_DUPFD> de B<fcntl>(2) ou B<fork>(2), un nouveau descripteur de fichier qui se réfère au même fichier ouvert est créé. Une description de fichier ouvert continue d'exister jusqu'à ce que tous les descripteurs de fichier qui s'y réfèrent soient fermés.

note: type: Plain text
en: A file descriptor is removed from an interest list only after all the file descriptors referring to the underlying open file description have been closed.  This means that even after a file descriptor that is part of an interest list has been closed, events may be reported for that file descriptor if other file descriptors referring to the same underlying file description remain open.  To prevent this happening, the file descriptor must be explicitly removed from the interest list (using B<epoll_ctl>(2)  B<EPOLL_CTL_DEL>)  before it is duplicated.  Alternatively, the application must ensure that all file descriptors are closed (which may be difficult if file descriptors were duplicated behind the scenes by library functions that used B<dup>(2)  or B<fork>(2)).
fr: Un descripteur de fichier n'est retiré d'une liste I<interest> qu'après la fermeture de tous les descripteurs de fichier qui se réfèrent à la description de fichier ouvert sous-jacente. Cela signifie que même après la fermeture d'un descripteur de fichier faisant partie de cette liste, des événements peuvent toujours être rapportés pour ce descripteur de fichier si d'autres descripteurs de fichier, se référant à la même description de fichier sous-jacente, restent ouverts. Pour empêcher cela, le descripteur de fichier doit être explicitement supprimé de la liste (en utilisant B<epoll_ctl>(2) B<EPOLL_CTL_DEL>) avant qu’il ne soit dupliqué. Autrement, l’application doit assurer que tous les descripteurs soient fermés (ce qui peut être difficile si les descripteurs ont été dupliqués en dehors du cadre par des fonctions de bibliothèque qui utilisent B<dup>(2) ou B<fork>(2))

note: type: Plain text
en: If more than one event occurs between B<epoll_wait>(2)  calls, are they combined or reported separately?
fr: Si plus d'un événement surviennent entre deux appels B<epoll_wait>(2), sont-ils combinés ou rapportés séparément\ ?

note: type: Plain text
en: They will be combined.
fr: Ils sont combinés.

note: type: Plain text
en: Does an operation on a file descriptor affect the already collected but not yet reported events?
fr: Est-ce qu'une opération sur un descripteur affecte les événements déjà collectés mais pas encore rapportés\ ?

note: type: Plain text
en: You can do two operations on an existing file descriptor.  Remove would be meaningless for this case.  Modify will reread available I/O.
fr: Vous pouvez faire deux choses sur un descripteur existant. Une suppression serait sans effet dans ce cas. Une modification revérifie les entrées et sorties disponibles.

note: type: Plain text
en: Do I need to continuously read/write a file descriptor until B<EAGAIN> when using the B<EPOLLET> flag (edge-triggered behavior)?
fr: Dois-je lire/écrire sans cesse un descripteur jusqu'à obtenir B<EAGAIN> si l'attribut B<EPOLLET> est utilisé (comportement par détection de changement d'état)\ ?

note: type: Plain text
en: Receiving an event from B<epoll_wait>(2)  should suggest to you that such file descriptor is ready for the requested I/O operation.  You must consider it ready until the next (nonblocking)  read/write yields B<EAGAIN>.  When and how you will use the file descriptor is entirely up to you.
fr: La réception d'un événement depuis B<epoll_wait>(2) suggère qu'un descripteur est prêt pour l'opération d'E/S désirée. Il doit être considéré comme prêt jusqu'à ce que la prochaine lecture ou écriture (non bloquante) remonte un B<EAGAIN>. Quand et comment utiliser le descripteur dépend de vous.

note: type: Plain text
en: For packet/token-oriented files (e.g., datagram socket, terminal in canonical mode), the only way to detect the end of the read/write I/O space is to continue to read/write until B<EAGAIN>.
fr: Pour les fichiers orientés paquet ou jeton (par exemple, un socket datagramme ou un terminal en mode canonique), la seule façon de détecter la fin de l'espace d'entrée et sortie pour les lectures ou écritures est de continuer à lire ou écrire jusqu'à la réception d'un B<EAGAIN>.

note: type: Plain text
en: For stream-oriented files (e.g., pipe, FIFO, stream socket), the condition that the read/write I/O space is exhausted can also be detected by checking the amount of data read from / written to the target file descriptor.  For example, if you call B<read>(2)  by asking to read a certain amount of data and B<read>(2)  returns a lower number of bytes, you can be sure of having exhausted the read I/O space for the file descriptor.  The same is true when writing using B<write>(2).  (Avoid this latter technique if you cannot guarantee that the monitored file descriptor always refers to a stream-oriented file.)
fr: Pour les fichiers orientés flux (par exemple, les tubes, FIFO ou sockets en mode flux), la disponibilité des entrées et sorties peut aussi être détectée en vérifiant la quantité de données lues ou écrites sur le descripteur. Par exemple, si vous appelez B<read>(2) en demandant la lecture d'une certaine quantité de données et que B<read>(2) en renvoie moins, vous pouvez être sûr d'avoir consommé tout le tampon d'entrée pour le descripteur. La même chose est vraie pour l'appel système B<write>(2) (évitez cette dernière technique si vous ne pouvez pas garantir que le descripteur de fichier surveillé corresponde toujours à un fichier de type flux).

note: type: SS
en: Possible pitfalls and ways to avoid them
fr: Erreurs possibles et moyens de les éviter

note: type: Plain text
en: If there is a large amount of I/O space, it is possible that by trying to drain it the other files will not get processed causing starvation.  (This problem is not specific to B<epoll>.)
fr: S'il y a un gros volume d’espace d’E/S, il est possible qu'en essayant de les traiter, d'autres fichiers ne soient pas pris en compte provoquant une famine. Ce problème n'est pas spécifique à B<epoll>.

note: type: Plain text
en: The solution is to maintain a ready list and mark the file descriptor as ready in its associated data structure, thereby allowing the application to remember which files need to be processed but still round robin amongst all the ready files.  This also supports ignoring subsequent events you receive for file descriptors that are already ready.
fr: La solution est de maintenir une liste de descripteurs prêts et de marquer le descripteur de fichier prêt dans leur structure associée, permettant à l'application de savoir quels fichiers traiter mais toujours en tourniquet englobant tous les fichiers prêts. Cela permet aussi d'ignorer les événements ultérieurs sur des descripteurs prêts.

note: type: Plain text
en: If you use an event cache or store all the file descriptors returned from B<epoll_wait>(2), then make sure to provide a way to mark its closure dynamically (i.e., caused by a previous event's processing).  Suppose you receive 100 events from B<epoll_wait>(2), and in event #47 a condition causes event #13 to be closed.  If you remove the structure and B<close>(2)  the file descriptor for event #13, then your event cache might still say there are events waiting for that file descriptor causing confusion.
fr: Si vous utilisez un cache d'événements, ou stockez tous les descripteurs renvoyés par B<epoll_wait>(2), alors assurez-vous de disposer d'un moyen de marquer dynamiquement leurs fermetures (c’est-à-dire causées par un traitement d’événement précédent). Supposons que vous recevez 100 événements d’B<epoll_wait>(2) et que l'événement 47 implique de fermer l’évènement 13. Si vous supprimez la structure et utilisez B<close>(2) pour le descripteur de fichier pour l’évènement 13, alors votre cache peut encore contenir des événements pour ce descripteur, posant alors des problèmes de confusion.

note: type: Plain text
en: One solution for this is to call, during the processing of event 47, B<epoll_ctl>(B<EPOLL_CTL_DEL>)  to delete file descriptor 13 and B<close>(2), then mark its associated data structure as removed and link it to a cleanup list.  If you find another event for file descriptor 13 in your batch processing, you will discover the file descriptor had been previously removed and there will be no confusion.
fr: Une solution est d'invoquer, pendant le traitement de l'événement 47, B<epoll_ctl>(B<EPOLL_CTL_DEL>) pour supprimer le descripteur 13, le fermer avec B<close>(2), puis marquer sa structure associée comme supprimée et la lier à une liste de nettoyage. Si vous rencontrez un autre événement pour le descripteur 13 dans votre traitement, vous verrez qu'il a été supprimé précédemment sans que cela ne prête à confusion.

note: type: SH
en: HISTORY
fr: HISTORIQUE

note: type: Plain text
en: The B<kcmp>(2)  B<KCMP_EPOLL_TFD> operation can be used to test whether a file descriptor is present in an epoll instance.
fr: L’opération B<B<KCMP_EPOLL_TFD> de B<kcmp>(2)> peut être utilisée pour tester si un descripteur de fichier est présent dans une instance d’B<epoll>.

note: type: SH
en: SEE ALSO
fr: VOIR AUSSI

note: type: TH
en: 2023-02-05
fr: 5 février 2023

note: type: TH
en: Linux man-pages 6.03
fr: Pages du manuel de Linux 6.03

note: type: Plain text
en: ev.events = EPOLLIN;
    ev.data.fd = listen_sock;
    if (epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_sock, &ev) == -1) {
        perror("epoll_ctl: listen_sock");
        exit(EXIT_FAILURE);
    }
fr: ev.events = EPOLLIN;
    ev.data.fd = listen_sock;
    if (epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_sock, &ev) == -1) {
        perror("epoll_ctl : listen_sock");
        exit(EXIT_FAILURE);
    }

note: type: Plain text
en: The B<epoll> API is Linux-specific.  Some other systems provide similar mechanisms, for example, FreeBSD has I<kqueue>, and Solaris has I</dev/poll>.
fr: L'API B<epoll> est spécifique à Linux. Certains autres systèmes fournissent des mécanismes similaires. Par exemple, FreeBSD propose I<kqueue> et Solaris I</dev/poll>.

note: type: TH
en: Linux man-pages 6.05
fr: Pages du manuel de Linux 6.05

note: type: TH
en: 2023-03-30
fr: 30 mars 2023

note: type: TH
en: Linux man-pages 6.04
fr: Pages du manuel de Linux 6.04
