Poster une réponse à un sujet: fd_set de select.h
Attention, ce sujet est un sujet ancien (6522 jours sans réponse)
philfr
Et bientôt, pour linux on aura kevent...
Altar
Epoll en level triggered a l'air bien
Altar
Hum merci du tuyeau, je vais regarder ça tantôt
philfr
Au fait, si tu développe avec select() sous linux 2.6, jette donc un coup d'oeil à epoll()...
philfr
C'est pas grave si le n que tu donnes est supérieur au plus grand fd. C'est juste un hint pour que le kernel ne doive pas parcourir toute l'array... ce qui est précisément ce que tu veux faire à sa place.
Augmente n si nécessaire à chaque fois que tu ajoutes un fd, mais ne le diminue jamais...
Ou alors, reconstruis un nouveau fd_set à partir de la liste des fd que tu as dans ton array (tu les as bien quelque part, non ?) avant chaque appel à select. Ce sera toujours plus efficace que de reparcourir le fd_set brut.
Augmente n si nécessaire à chaque fois que tu ajoutes un fd, mais ne le diminue jamais...
Ou alors, reconstruis un nouveau fd_set à partir de la liste des fd que tu as dans ton array (tu les as bien quelque part, non ?) avant chaque appel à select. Ce sera toujours plus efficace que de reparcourir le fd_set brut.
Altar
philfr > C'est moi qui donne les fd Mais je ne les donne qu'une fois et je crée une copie de mon fd_set "original" avant chaque appel à select. Malheureusement après si je décide de retirer le plus grand fd, je ne sais pas retrouver le suivant à moins de parcourir mon fd_set...
Oui je pourrais créer une structure qui ressemble vachement à un fd_set et puis faire plein de FD_SET(fd,&fd_set) mais je pense que la copie d'un array de long ira plus vite que la mise à jour bit par bit
Oui je pourrais créer une structure qui ressemble vachement à un fd_set et puis faire plein de FD_SET(fd,&fd_set) mais je pense que la copie d'un array de long ira plus vite que la mise à jour bit par bit
philfr
philfr > J'aimerais bien retrouver le plus grand fd à partir du fd_set (pour la première variable de select).
C'est toi qui donnes les fd, donc tu fixes n à la valeur du plus grand fd+1.
Si tu reçois le fd_set d'un autre API (d'où ça ?), c'est lui qui doit te donner ce n.
Je peux faire le porc dans l'autre sens et créer un fd_set puis le caster comme un pointeur de long et faire mes opérations dessus si tu trouves que c'est plus safe...
C'est presque pire
Mais tu ne devrais pas avoir d'autres opérations à faire que celles implémentées dans les macros standard.
zion
Négatif, ce type n'existe pas sous Delphi
Le jour où j'ai dû l'utiliser j'ai bien été obligé de faire mon array de long à la place
Le jour où j'ai dû l'utiliser j'ai bien été obligé de faire mon array de long à la place
Altar
philfr > J'aimerais bien retrouver le plus grand fd à partir du fd_set (pour la première variable de select).
Je peux faire le porc dans l'autre sens et créer un fd_set puis le caster comme un pointeur de long et faire mes opérations dessus si tu trouves que c'est plus safe...
Je peux faire le porc dans l'autre sens et créer un fd_set puis le caster comme un pointeur de long et faire mes opérations dessus si tu trouves que c'est plus safe...
philfr
Utiliser le type fd_set est safe, puisqu'on l'utilise avec les API faits pour, et que si on recompile sur un autre OS/compilo, ça doit marcher par définition.
Faire la supposition que fd_set est une structure d'arrays de long et utiliser ça à la place ne l'est pas (safe)...
Edit: delphi ne supporte pas le select ?
Faire la supposition que fd_set est une structure d'arrays de long et utiliser ça à la place ne l'est pas (safe)...
Edit: delphi ne supporte pas le select ?