Timers - Page 1

Est ce qu'il y a des fonction de timers C standard? sinon dans quelle libs peut on en trouver.

Standard...
Le standard POSIX (je crois) permet d'intercepter les signaux d'un processus (Genre On Signal Run function).
Et on peut preciser de lancer un signal au bout d'un certain temps.
Avec ca on peut se debrouiller.
Mais c'est pas compatible Windows (La couche Posix Windows est TRES limite).

y'a pas de fonction standard, mais si tu bosses sous Windows tu peux utiliser l'API Windows qui permet de générer des Timers grâce à la fonction SetTimer.
Ne pas oublier de les détruire avec KillTimer.

Sinon moyen bourrin mais efficace, utilise des threads

main()
{
 //[...]
 //Code principal
 //Creation du "timer"
 CreateThread(Timer1,[...]); // pour les param RTFM hein ;)
 //[...]
}

void Timer1(void dummy)
{
 while(1)
 {
  sleep(1000); // Temps du "timer" ici 1 seconde

 //Code a faire toutes les 1 seconde

 }
}

Apres tu peut faire mumuse avec des variables globales+mutex pour gerer l'arret ou pas du timer (ou avec d'autres moyen de communication avec le thread, mais TOUJOURS proteger l'accée au variables communes entre le thread et le programme principal avec quelque chose comme les mutex ou autre)

Si tu veux un exemple avec mutex, demande moi

Les threads sont non portables aussi

si les thread sont portable, car il existe une définition POSIX des threads

Oui, mais tu as toujours des machines exotiques qui font n'importe quoi avec les threads.
Enfin, apres tout, tout est de savoir a quel point on veut etre portable.

oui

heu le sleep c'est pas en secondes normalement?

Non le Sleep (de windows en tout cas) est en miliseconde

bah mon man me dit que c'est en secondes

C'est pas la commande sleep du shell, et pas la fonction sleep ?

non j'ai fait:
man 3 sleep

Ba si tu est sous linux

linux et les threads :/

sa fait 42, donc si tu fait ton truc sous nux, je croit qu'il faut oublier ma solution....


Edit: Ma phrase etait pas forcement tres clair

Tu connais la NPTL?

C quoi le pb de linux avec les threads? (à part qu'il vaut mieux faire des process )

Ben linux est tres loins de suivre la normalisation posix pour les threads..

Genre CreateThread a un argument qui peut normalement etre a NULL et linux ne supporte pas ça (il fait un segfault)

Et la partie du scheduler du kernel 2.4 gerant les thread est affreuse.. la 2.6 corrigerait ça, mais j'y croit moyennement...

Ah.

bon j'ai résolu le problème avec avec setitimer

godzil
: Ben linux est tres loins de suivre la normalisation posix pour les threads..

On se demande si tu sais lire...

Kevin Kofler
: Tu connais la NPTL?

NPTL : The Native POSIX Thread Library for Linux

Je viens de voir, mais ce n'est pas NATIF au kernel donc je trouve pas sa interessant car pas "standard" au distri linux.

Et cela ne change pas la gestion catastrophique des threads sous Linux 2.4.x

(pour info Linux gere les threads comme des processus dans un espace mémoire completement différent du thread principal, ce qui peut etre dans bcp de cas tres génant...)

godzil :
NPTL : The Native POSIX Thread Library for Linux
Je viens de voir, mais ce n'est pas NATIF au kernel donc je trouve pas sa interessant car pas "standard" au distri linux.

C'est inclus dans RedHat 9 et supérieures. Si les autres distributions sont en retard, tant pis. Et pour le non-natif, pourquoi à ton avis ça s'appelle "Native POSIX Thread Library"??? Justement, c'est fait avec le support du kernel (version 2.5.36 ou supérieures, ou une 2.4.x patchée).

Et cela ne change pas la gestion catastrophique des threads sous Linux 2.4.x

Et RedHat 9, ce n'est pas du 2.4.x à ton avis?

Redhat sux..... et tout le monde n'utilise pas redhat dsl

Si c'est NON NATIF, c'est que se n'est pas INCLUS DIRECTEMENT dans les sources du KERNEL !


D'ailleur RedHat a une bonne réputation de mettre des version NON Officielle de certain programmes (pour ne pas citeer GCC 2.96, une version Bug featured de XFree et autres) ainsi qu'une forte non volonté de partager leur patchs avec les devellopeurs de programme libres, bref RedHat ->

godzil
: Redhat sux..... et tout le monde n'utilise pas redhat dsl

Les autres distributions n'ont qu'à ne pas être en retard.

D'ailleur RedHat a une bonne réputation de mettre des version NON Officielle de certain programmes (pour ne pas citeer GCC 2.96, une version Bug featured de XFree et autres) ainsi qu'une forte non volonté de partager leur patchs avec les devellopeurs de programme libres, bref RedHat ->

Tu sais, leurs patches aux logiciels GPL sont sous GPL, il suffit de les prendre.

Et TIGCC pour Linux/Unix est compilé avec GCC 2.96-rh depuis la 0.95 bêta 18 r1, et il n'y a jamais eu de problèmes.

Rensinement toi kevin...

GCC 2.96 est tout sauf officiel, et il s'agit de la version la plus buggé de GCC.....

La première 2.96-rh était boguée, mais les bogues ont été corrigées avec le temps. La 2.96-113 est moins boguée que certaines 3.x officielles.