pourquoi select en particulier?

Une question, toute bête, mais pourquoi tu t'emmerdes avec select()?

Ce n'est que m'on avis personnel, mais je trouve les codes qui utilisent select imbuvables, poll me semble tellement plus lisible, plus intuitif:

• tu initialise un tableau qui contiens autant d'instances de pollfd que de fd à surveiller, ces structures contenant: le fd en question, un bitfield uniquement lu (donc, pas besoin de le réécrire après un appel, contrairement à select de mémoire) qui contiens les évènements à surveiller, un autre uniquement accédé en écriture. Accessoirement, le timeout est juste un entier en millisecondes, je trouve ça tellement plus simple.
• tu le passes à poll.
• tu récupères le nombre d'évènements et tu itères sur ton tableau pour voir quelles structures ont leur revent pas à 0
• le tour est joué.

Au niveau avantages:

• pas besoin de rafraîchir les tableaux qui contiennent les files à surveiller
• une seule structure pour tous les types d'évènements
• pas de limitation hard-codée par le système (donc, pas de gâchis d'espace ni de limitations dans le nombre de descripteurs à surveiller)
• pas de macros (donc des messages d'erreur plus simples à comprendre et en cadeau bonus une type safety un peu moins crade)
• données mémoire plus compacte
• on peut désactiver la surveillance sur un fd en lui affectant une valeur négative, tandis que select requiert uniquement des fd valides.

Les inconvénients... je n'en connais pas. Ah, si, la doc indique que c'est un peu plus récent (POSIX.1-2001, contre une apparition de select dans 4.4BSD) mais franchement, ça fait quand même plus de 15 ans, ça devrait le faire sur la plupart des systèmes.

Bon, tu fais ce que tu veux, mais ton bug est très probablement lié au fait que, justement, select ait une interface dégueulasse:

 rv_select = select(usbfile_select+1, &set, NULL, &set, &timeoutValue);

Tu utilises 2 fois la même structure, du coup, select, ben, il écrit 2 fois dedans...