Techniquement cela ne devrait avoir aucun effet. Mais vous devez vous rappeler que la valeur transmise est utilisée comme minimum , et non un absolu, donc le système est libre d'utiliser à la place le plus petit intervalle possible.
Je voulais juste souligner la commande time utilisée ici. Vous devez utiliser /usr/bin/time au lieu de seulement time commande si vous voulez vérifier la mémoire de votre programme, le processeur, le temps stat. Lorsque vous appelez time sans chemin complet, la commande time intégrée est appelée. Regardez la différence.
sans chemin complet :
# time -v ./a.out
-bash: -v: command not found
real 0m0.001s
user 0m0.000s
sys 0m0.001s
avec le chemin complet :
# /usr/bin/time -v ./a.out
Command being timed: "./a.out"
User time (seconds): 0.00
System time (seconds): 0.00
Percent of CPU this job got: 0%
Elapsed (wall clock) time (h:mm:ss or m:ss): 0:10.87
Average shared text size (kbytes): 0
Average unshared data size (kbytes): 0
Average stack size (kbytes): 0
Average total size (kbytes): 0
Maximum resident set size (kbytes): 0
Average resident set size (kbytes): 0
Major (requiring I/O) page faults: 0
Minor (reclaiming a frame) page faults: 220
Voluntary context switches: 10001
Involuntary context switches: 1
Swaps: 0
File system inputs: 0
File system outputs: 0
Socket messages sent: 0
Socket messages received: 0
Signals delivered: 0
Page size (bytes): 4096
Exit status: 0
utilisez man time pour /usr/bin/time manuel et utilisez help time pour les informations temporelles intégrées.
Je devrais regarder la source pour m'en assurer, mais je suppose que ce n'est pas tout à fait "aucun effet", mais c'est probablement encore moins que usleep(1) - il y a toujours la surcharge d'appel de fonction, qui peut être mesurable dans une boucle serrée, même si l'appel de la bibliothèque vérifie simplement ses arguments et revient immédiatement, évitant le processus plus habituel de configuration d'une minuterie/rappel et d'appel du planificateur.