[timer & thread] timeout & socket non bloquant

Version imprimable

16/08/2007, 14h27
untipy

[timer & thread] timeout & socket non bloquant

bonjour
Un thread lance un timer (qui fonctionne bien). Comment faire simplement opur que la thread soit informé du timeout de ce timer . J'ai pensé à la création d'une pipe entre le deux mais y a t'il plus simple? Petre avec la gestion des signaux (unix)?
merci
16/08/2007, 19h06
nicolas.sitbon

Mets un bout de code au moins s'il te plait car on sait même pas de quelle thread tu parles (main ou fille).
Cordialement.

Voici le programme de la thread. a un moment donné elle lance le timer. Mais comment lui dire que letimeout est franchi

Code:

1
2
3
4
5
6
Thread  {
...
startimer();
...
 
}

le prog timer:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
void action() {...}
 
void starttimer() {
#ifdef BSD
signal(SIGALRM, action);
#else
struct sigaction act;
act.sa_handler = action;
act.sa_flags = SA_RESTART;
if(sigaction(SIGALRM, &act, NULL) == -1) {
    fprintf(stderr, "error %d in sigaction\n");
}
#endif                                                               
tempo.it_interval.tv_sec = INTERVAL_SEC;                                        
tempo.it_interval.tv_usec = INTERVAL_MICROSEC;                                  
tempo.it_value.tv_sec = INTERVAL_SEC;                                           
tempo.it_value.tv_usec = INTERVAL_MICROSEC;                                     
setitimer(ITIMER_REAL, &tempo, 0);     
}

17/08/2007, 08h42
Emmanuel Delahaye

Citation:

Envoyé par untipy

Voici le programme de la thread. a un moment donné elle lance le timer. Mais comment lui dire que letimeout est franchi
<...>

En général, on utilise select() pour bloquer la boucle du thread. On peut régler un timeout.
17/08/2007, 08h50
untipy

ok, mais j'aimerai ne pas bloqué le thread, car le timer peux etre long, et la thread doit faire autre chose a coté.
en fait je voudrais gérer çà comme une interruption et la ... ail ....!!
17/08/2007, 08h51
untipy

dans la fonction action() peux t'on ajouté un lien vers la thread pour lui dire 'timer fini'??
17/08/2007, 09h10
Emmanuel Delahaye

Citation:

Envoyé par untipy

ok, mais j'aimerai ne pas bloqué le thread, car le timer peux etre long, et la thread doit faire autre chose a coté.
en fait je voudrais gérer çà comme une interruption et la ... ail ....!!

En principe, un thread est bloqué et ne se débloque que sur évènements. Avec select(), les évènements sont (pour simplifier) :

- échéance du timer()
- réception sur flux entrant (y compris sockets)
- émission sur flux sortant (idem)

Une interruption et un thread sont deux concepts différents. Tu peux néanmoins débloquer un thread cycliquement si tu veux faire une sorte de polling en réglant le timeout de select() sur une valeur courte (tick)... Tu peux alors gérer un timeout long en comptant les ticks... Tout dépend de l'application.

Nota : un thread qui tourne en permanence (boucle 'blanche') est considéré comme 'asocial"'. Il doit y avoir au moins une suspension (sleep(1)) dans la boucle pour laisser le système respirer, surtout si il est de type 'coopératif' (Linux, par exemple).
17/08/2007, 09h13
Emmanuel Delahaye

Citation:

Envoyé par untipy

dans la fonction action() peux t'on ajouté un lien vers la thread pour lui dire 'timer fini'??

Personnellement, j'utilise un flag du contexte pour signaler la fin à un thread 'fils'. Je crois qu'il y a des exemples dans mon article...

http://emmanuel-delahaye.developpez.com/pthreads.htm
17/08/2007, 09h34
untipy
j'ai inséré un flag dans le prog timer

Code:

void action() { toto=1;}

et toto est globale, connu de la thread également
mais celle-ci ne le voit pas
prog thread
Code:

1 2 3 4 5 6 7 8 while (1){ ... if (toto ==1){ printf("\nVAL TOTO:%d\n",toto); toto=0; } ... }
17/08/2007, 10h08
untipy

j'ai trouvé en fait le drapeau fonctionne mais a un moment dans le prgramme thread j'utilise la fonction read et cette fonction est bloquante ...
17/08/2007, 10h40
nicolas.sitbon

Citation:

surtout si il est de type 'coopératif' (Linux, par exemple)

Linux n'est pas coopératif, il utilise 3 politiques d'ordonnancement : la première pour les processus ordinaire, et les 2 autres pour les processus temps réels.
La politique appliquée varie selon le type de processus qui peut être soit SCHED_FIFO (temps réel non préemptible), soit SCHED_RR (temps réel préemptible) soit SCHED_OTHER (processus ordinaire préemptible).
Enfin untipy pourquoi utilises-tu signal() au lieu de sigaction dans le cas d'un bsd?
17/08/2007, 10h48
untipy

si si j'utilise bien signal()

mais comment rendre un read() non bloquant, si il n'y a rien on continue l'éxécution du prog

c'est recv() ???
17/08/2007, 10h55
nicolas.sitbon

J'attend toujours que tu postes ton code en entier sinon c'est du bricolage et on risque de perdre plus de temps qu'autre chose.
Cordialement.

oups !!

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
void *thread(void *param)
int sck = *((int *) param);
while(1)
{
if (toto ==1)
{
printf("timeout");
}
 
len = recv (sck,msg,sizeof msg - 1,0);
if(len < 0)
{ ...}
/*apres c'est du traitement sur msg*/
}

en fait je suis parti sur çà :
utilisation d'un timer

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 fd_set rfds;
            struct timeval tv;
            int retval;
            FD_ZERO(&rfds);
            FD_SET(sck, &rfds); /* on ajoute la socket a regarder */
            tv.tv_sec = 2;
            tv.tv_usec = 0;
            retval = select(0, &rfds, NULL, NULL, &tv);
 
            if (retval)
            {
                /* infos reçues sur sck dans les 2 secondes*/
                len = read(sck,msg,4096);
}
else{printf"rienr recu");}

mais il détecte jamais rien en entrée du socket :( :?

17/08/2007, 15h46
untipy

est-ce qq'un a un exemple de lecture sur socket non bloquant, que je puisse debbugé mon prog svp ?

:bug:
17/08/2007, 16h03
Emmanuel Delahaye

Citation:

Envoyé par untipy

est-ce qq'un a un exemple de lecture sur socket non bloquant, que je puisse debbugé mon prog svp ?

Pourquoi faire un socket non bloquant .? C'est absurde et contre productif. Si on utilise les threads c'est pour que ça bloque sauf quand traire (réception etc.).

Refait ta conception en mode bloquant, tu verras que c'est beaucoup plus clair et plus simple. Des traitements en parallèle ? Faire plusieurs threads 'socialement corrects'...
17/08/2007, 16h30
untipy

Voila j'ai trouvé mon bug .... oufff
alors petit retour d'expérience si cela peut être utile a d'autres programmeurs ...

je suis sur linux
donc pour faire une socket non bloquant en lecture, il faut configurer la fonction select

Code:

int select( int nfds,fd_set* readfds,fd_set* writefds,fd_set* exceptfds,const struct timeval* timeout );

sachant que nfds : [doit valoir le plus grand identifiant de socket, plus 1 (non utilisé sous Windows).

Code:

int select( socket+1,...)

Le plus 1 est SUPER important, c'était mon bug. (Le code qui va avec cette explication est page 1 en bas)
:D

je fais cela car je fait du polling sur plusieurs socket ... y a plus classe ?
17/08/2007, 17h10
Emmanuel Delahaye

Citation:

Envoyé par untipy

je suis sur linux
donc pour faire une socket non bloquant en lecture, il faut configurer la fonction select

Non, rien à voir.

Citation:

Code:

int select( int nfds,fd_set* readfds,fd_set* writefds,fd_set* exceptfds,const struct timeval* timeout );

sachant que nfds : [doit valoir le plus grand identifiant de socket, plus 1 (non utilisé sous Windows).

Code:

int select( socket+1,...)

Le plus 1 est SUPER important, c'était mon bug.
:D

je fais cela car je fait du polling sur plusieurs socket ... y a plus classe ?

Bah oui. Tous les sockets sont bloquants (c'est le mode par défaut et ici, ça n'a pas beaucoup d'importance) et select() t'indique lequel s'est réveillé.

http://emmanuel-delahaye.developpez....aux.htm#select

En fait, c'est select() qui est bloquant ici et qui fait le tri...

Citation:

Envoyé par untipy

Voila j'ai trouvé mon bug .... oufff
alors petit retour d'expérience si cela peut être utile a d'autres programmeurs ...

je suis sur linux
donc pour faire une socket non bloquant en lecture, il faut configurer la fonction select

Code:

int select( int nfds,fd_set* readfds,fd_set* writefds,fd_set* exceptfds,const struct timeval* timeout );

sachant que nfds : [doit valoir le plus grand identifiant de socket, plus 1 (non utilisé sous Windows).

Code:

int select( socket+1,...)

Le plus 1 est SUPER important, c'était mon bug. (Le code qui va avec cette explication est page 1 en bas)
:D

je fais cela car je fait du polling sur plusieurs socket ... y a plus classe ?

Comme a dit Emmanuel, dans ton exemple tu n'utilises pas les sockets non bloquants, mais le select.

Pour un socket non bloquant, il faut le passer en mode asynchrone...du style :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 pid =getpid(); bidon = (int) pid; #ifndef LINUX retour = ioctl(requete,SIOCSPGRP,&bidon); #else retour = fcntl(requete,F_SETOWN,(long)bidon); #endif if ( retour < 0 ) return retour ; /* *Initialiser l'option asynchrone pour le socket */ #ifndef LINUX bidon = 1; retour = ioctl(requete,FIOASYNC,&bidon); #else bidon = O_ASYNC ; retour = fcntl(requete,F_SETFL,(long)bidon); #endif
ET PUIS ajouter une routine de réception par signal :
Code:

1 2 signal(SIGIO,fonction);
Note1 : Attention, dans le code donné ci-dessus, le "else" veut dire un autre système au moins unixoide (en tous cas pas Windows, car les appels ne sont pas les mêmes pour les sockets).

Note2 : il faut bien entendu inclure ioctl.h ou fnctl.h, plus signal.h, et vraisemblablement vérifier les définitions des signaux (il est possible que les POLL ne soient pas définis, suivant la version du kernel).

Ensuite, il n'est pas certain que le poll t'indique ce que tu veux. Il faut vérifier par rapport aux file descriptor. Il peut également indiquer une rupture de communication, que ce soit du fait d'un client, du serveur, ou d'un kill ou d'un ctrlC.

Mais c'est effectivement la philosophie à utiliser pour un serveur à multpile clients (et éventuellement multiples esclaves).

21/08/2007, 08h13
untipy

Merci pour vos réponses, elles ont clarifié certaines choses
;)
21/08/2007, 09h44
untipy

bonjour

a titre d'info uniquement, avez vous un exemple d'un accept non bloquant

etape 1:

Code:

sock = socket(PF_INET,SOCK_STREAM,0))

etape 2: gestion des option
etape 3 : Configuration de l'adresse et du port
etape 4 :Configuration du nombre d'écoute
tout ca c ok

atepa 5 : accept connexion :

Code:

sock2 = accept(sock, NULL, 0))

cette fonction est bloquant ...
alors j'ai voulu faire un select avant mais cela marche pas, en effet la valeur retournée apres le teimeout soit sock2 est 1230976571 quand il n'y a pas de connexion etablie.
Or la valeur renvoyée par accept est un nombre non négatif lors d'un succès, et -1 lors d'un échec. Donc il considere qu'il y a un client
????
merci de votre aide
21/08/2007, 09h46
Emmanuel Delahaye

Citation:

Envoyé par untipy

a titre d'info uniquement, avez vous un exemple d'un accept non bloquant

Oublie cette idée de "non bloquant". C'est contre-productif. Fait un thread par connexion et c'est tout.
21/08/2007, 09h52
untipy

ok je vais suivre ce conseil
et pour communiquer proprement entre thread : des pipes ?
cela va me faire un paquet de thread a gerer !!
21/08/2007, 09h56
Emmanuel Delahaye

Citation:

Envoyé par untipy

ok je vais suivre ce conseil
et pour communiquer proprement entre thread : des pipes ?

Des contextes suffisent. La mémoire est partagée par définition. Mais c'est rarement nécessaire...
21/08/2007, 10h02
untipy

ok ben je vais faire attention ; utilisation d'un bon vieux mutex (ou plusiers )
je n'utilisait pas pas le select avant, pas confronter a cette situation ...
21/08/2007, 10h06
Emmanuel Delahaye

Citation:

Envoyé par untipy

ok ben je vais faire attention ; utilisation d'un bon vieux mutex (ou plusiers )...

Oui.

http://emmanuel-delahaye.developpez.com/pthreads.htm
21/08/2007, 10h10
untipy

En fait, voici un bref descriptif de mon exemple, j'ai une thread qui gère les connexion de clients sur deux ports, pour chaque nouveaux clients elle associe une nouvelle thread.
Le fait d'utiliser ce principe avec la thread relative a la gestion des connexion me simplifiait la vie mais fonction accept bloquante

Citation:

Envoyé par untipy

En fait, voici un bref descriptif de mon exemple, j'ai une thread qui gère les connexion de clients sur deux ports, pour chaque nouveaux clients elle associe une nouvelle thread.
Le fait d'utiliser ce principe avec la thread relative a la gestion des connexion me simplifiait la vie mais fonction accept bloquante

Je ne vois pas où est le problème. Il est parfaitement logique que le thread principal du serveur soit bloqué sur accept(). C'est fait pour...

Pseudo-code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 thread_client(cli) { DO receive(cli.sock, data) ; blocant process (data) WHILE NOT cli.fin delete cli } thread_serveur() { DO new cli accept(cli) ; blocant create_thread(thread_client, cli) FOREVER }

21/08/2007, 10h28
untipy

ou je suis entierement d'accord pour un port mais si le serveur doit gérer plusieurs ports (A et B). le serveur va attendre une connexion sur la part A alors qu'un client va vouloir se connecter sur le port B. Sauf si on eclate le serveur en 2 thread : ca complique , non?
c'est pour cela que je voulais rendre accept non bloquante avec timer pour eviter qu'elle soit associable
21/08/2007, 10h52
Emmanuel Delahaye
Citation:

Envoyé par untipy

ou je suis entierement d'accord pour un port mais si le serveur doit gérer plusieurs ports (A et B). le serveur va attendre une connexion sur la part A alors qu'un client va vouloir se connecter sur le port B.

Un accept() ne peut pas surveiller 2 ports. Il faut une instance du thread serveur par port (listen())...

Citation:

Sauf si on eclate le serveur en 2 thread : ca complique , non?

Ben non, au contraire... 1 code, 2 instances...
Code:

1 2 3 4 5 6 7 8 9 10 11 thread_serveur(srv) { listen(srv.port) DO new cli accept(cli) ; blocant create_thread(thread_client, cli) FOREVER }
21/08/2007, 15h11
untipy

Merci de votre aide, elle a été precieuse.:D

En ce qui me concerne, je pense avoir fait le tour de toutes mes interrogations.

Puis-je fermer cette discution, si il n'y a plus d'autres questions .... ???
21/08/2007, 15h41
Emmanuel Delahaye

Citation:

Envoyé par untipy

Puis-je fermer cette discution, si il n'y a plus d'autres questions .... ???

C'est ton thread, tu en fais ce que tu veux...
22/08/2007, 08h37
untipy

ok,
Merci