Dans les deux cas, c'est du polling et c'est à éviter chaque fois que possible. Mieux tu regardes du côté de alarm() :
man 2 alarm
Les seuls avantages de cron, c'est de ne pas lancer un nouveau daemon exprès, et surtout de ne pas laisser dormir inutilement les processus en mémoire s'ils ne servent à rien. Mais pour le reste, c'est assez sauvage. Ton application est dépendante de cron, et déclencher un truc toutes les minutes x nombre d'utilisateurs, tu risques de le sentir passer. Ton crond va gagner des places en temps cpu cumulé.
Moi je partirai quand même sur un daemon dédié. Moins lourd, plus fiable. Ensuite, c'est de la conception : tu ne te réveilles pas toutes les minutes pour voir si c'est l'heure, mais à la place, tu prends les directives de tous les users, tu les tries par ordre chronologique, tu calcules le nombre de seconde entre l'instant présent et le premier de la liste, tu te mets en attente pour cette durée exacte, tu fais ce qu'il y a à faire et tu recommences avec l'entrée suivante.
Pour ce faire, tu peux effectivement faire un sleep(), mais tu seras réveillé au moindre signal (notamment celui de alarm()), donc il faudra pendre cela en charge. Mieux : tu crées un socket et tu l'écoutes avec select() dans une boucle principale. De cette manière, tu es sûr de ne pas te réveiller sans raison valable et tu peux communiquer avec ton daemon quand il n'est pas occupé à autre chose. Tu n'as même pas besoin de lancer de nouveaux threads. Cerise sur le gâteau : select() accepte une valeur de timeout facultative, qui te permet de sortir de l'état d'attente au bout d'une durée fixe, même si aucun événement n'a eu lieu.
En tout état de cause, et encore une fois, évite le réveil périodique minute par minute, surtout avec un sleep (60) car tu ne sais jamais à quel moment de la minute tu vas te réveiller. Si c'est à 00h00m59s, par exemple, tu auras 59 secondes de retard et dans certains cas, cela peut être préjudiciable à l'utilisateur.
# cron vs sleep() ?
Posté par Obsidian . En réponse au message Cron ou sleep() ?. Évalué à 6.
man 2 alarm
Les seuls avantages de cron, c'est de ne pas lancer un nouveau daemon exprès, et surtout de ne pas laisser dormir inutilement les processus en mémoire s'ils ne servent à rien. Mais pour le reste, c'est assez sauvage. Ton application est dépendante de cron, et déclencher un truc toutes les minutes x nombre d'utilisateurs, tu risques de le sentir passer. Ton crond va gagner des places en temps cpu cumulé.
Moi je partirai quand même sur un daemon dédié. Moins lourd, plus fiable. Ensuite, c'est de la conception : tu ne te réveilles pas toutes les minutes pour voir si c'est l'heure, mais à la place, tu prends les directives de tous les users, tu les tries par ordre chronologique, tu calcules le nombre de seconde entre l'instant présent et le premier de la liste, tu te mets en attente pour cette durée exacte, tu fais ce qu'il y a à faire et tu recommences avec l'entrée suivante.
Pour ce faire, tu peux effectivement faire un sleep(), mais tu seras réveillé au moindre signal (notamment celui de alarm()), donc il faudra pendre cela en charge. Mieux : tu crées un socket et tu l'écoutes avec select() dans une boucle principale. De cette manière, tu es sûr de ne pas te réveiller sans raison valable et tu peux communiquer avec ton daemon quand il n'est pas occupé à autre chose. Tu n'as même pas besoin de lancer de nouveaux threads. Cerise sur le gâteau : select() accepte une valeur de timeout facultative, qui te permet de sortir de l'état d'attente au bout d'une durée fixe, même si aucun événement n'a eu lieu.
En tout état de cause, et encore une fois, évite le réveil périodique minute par minute, surtout avec un sleep (60) car tu ne sais jamais à quel moment de la minute tu vas te réveiller. Si c'est à 00h00m59s, par exemple, tu auras 59 secondes de retard et dans certains cas, cela peut être préjudiciable à l'utilisateur.