Héhé, certes select() retournera avant le timeout s'il y a de l'activité sur les sockets... Mais sur un grand nombre de sockets, elle est quand même pénalisante car:
- le kernel scanne tous les sockets du FD_SET avant de retourner, il ne retourne pas dès qu'un socket a été trouvé prêt.
- select() retourne certes le nombre de socket prêts, mais il faut scanner tout le tableau de fds pour les retrouver.
- le nombre de fds enregistrable dans un set varie suivant l'OS et est parfois très limité (64 fds sous Windows...). L'implémentation des macros FD_* varie aussi suivant l'OS: sous GNU/Linux, c'est effectivement une affaire de bitmask, donc c'est rapide, mais sous Windows, chaque appel à FD_ISSET() scanne tout le tableau...
Le gros avantage de l'API epoll, c'est qu'on enregistre son fd et sa structure associée avec epoll_ctl, et qu'on reçoit ensuite directement un (ou plusieurs) fd prêt et sa structure avec epoll_wait. Donc pas de scans, pas de limitation de nombre de fds, et une notification immédiate. Dommage que ça ne soit pas portable !
J'ai regardé à quoi correspondait les proactor patterns, en diagonale, et ça ressemble furieusement au principe des I/Os asynchrones couplées avec un mécanisme de notification à la completion... Genre le hack SIGIO pour GNU/Linux ou les I/O completion ports sous Windows NT. C'est très puissant, mais pas portable non plus :) Quant au reactor, ça semble plus proche du principe d'epoll, select ou poll, avec des I/Os synchrones.
Donc en fait, j'aimerais arriver à avoir un truc proche de epoll en utilisant select() (ou autre chose de portable), mais je me demande si c'est très faisable...
[^] # Re: Pas clair
Posté par JaguarWan . En réponse au message Polling. Évalué à 1.
Héhé, certes select() retournera avant le timeout s'il y a de l'activité sur les sockets... Mais sur un grand nombre de sockets, elle est quand même pénalisante car:
- le kernel scanne tous les sockets du FD_SET avant de retourner, il ne retourne pas dès qu'un socket a été trouvé prêt.
- select() retourne certes le nombre de socket prêts, mais il faut scanner tout le tableau de fds pour les retrouver.
- le nombre de fds enregistrable dans un set varie suivant l'OS et est parfois très limité (64 fds sous Windows...). L'implémentation des macros FD_* varie aussi suivant l'OS: sous GNU/Linux, c'est effectivement une affaire de bitmask, donc c'est rapide, mais sous Windows, chaque appel à FD_ISSET() scanne tout le tableau...
Le gros avantage de l'API epoll, c'est qu'on enregistre son fd et sa structure associée avec epoll_ctl, et qu'on reçoit ensuite directement un (ou plusieurs) fd prêt et sa structure avec epoll_wait. Donc pas de scans, pas de limitation de nombre de fds, et une notification immédiate. Dommage que ça ne soit pas portable !
J'ai regardé à quoi correspondait les proactor patterns, en diagonale, et ça ressemble furieusement au principe des I/Os asynchrones couplées avec un mécanisme de notification à la completion... Genre le hack SIGIO pour GNU/Linux ou les I/O completion ports sous Windows NT. C'est très puissant, mais pas portable non plus :) Quant au reactor, ça semble plus proche du principe d'epoll, select ou poll, avec des I/Os synchrones.
Donc en fait, j'aimerais arriver à avoir un truc proche de epoll en utilisant select() (ou autre chose de portable), mais je me demande si c'est très faisable...