pas d'evenement, les fonctions sont non bloquantes ils faut utiliser un thread
1°) Un thread bloqué en lecture (en attente de données), 2°) Un autre thread qui écrit sur la même socket que celle bloquée par le thread n° 1,
La fonction socketecrit met 2 à 3 secondes pour s'exécuter.
Si la socket n'est pas bloquée en lecture, aucun problème, socketécrit s'exécute immédiatement.
Donc, j'aimerai ne pas bloquer la socket et savoir quand il y a une réception ou une connexion.
patrice
pas sur qu'une socket soit partageable entre 2 thread. si tes threads sont en mode automatique, il est possible que windev considere la socket comme une section critique et te bloque.
De toute facon, pour qu'une liaison socket fonctionne correctement, il vaut mieux que quand tu envoi, l'autre en face recoive (hormis pour des tres faible débit style telnet) sinon tu risque de perdre de l'info quand les buffers seront plein. donc AMHA, si c'est possible, essaie de mettre en place un protocole pour savoir a qui le tour de parler, et a qui le tour d'écouter
ca fait quoi ton soft ?
"//" a écrit dans le message de news:
patrice a formulé ce dimanche :
> pas d'evenement, les fonctions sont non bloquantes > ils faut utiliser un thread
1°) Un thread bloqué en lecture (en attente de données), 2°) Un autre thread qui écrit sur la même socket que celle bloquée par le thread n° 1,
La fonction socketecrit met 2 à 3 secondes pour s'exécuter.
Si la socket n'est pas bloquée en lecture, aucun problème, socketécrit s'exécute immédiatement.
Donc, j'aimerai ne pas bloquer la socket et savoir quand il y a une réception ou une connexion.
pas sur qu'une socket soit partageable entre 2 thread.
si tes threads sont en mode automatique, il est possible que windev
considere la socket comme une section critique et te bloque.
De toute facon, pour qu'une liaison socket fonctionne correctement, il vaut
mieux que quand tu envoi, l'autre en face recoive
(hormis pour des tres faible débit style telnet)
sinon tu risque de perdre de l'info quand les buffers seront plein.
donc AMHA, si c'est possible, essaie de mettre en place un protocole pour
savoir a qui le tour de parler, et a qui le tour d'écouter
ca fait quoi ton soft ?
"//" <email@domain.ext> a écrit dans le message de
news:mn.a5747d754bd68e26.67031@domain.ext...
patrice a formulé ce dimanche :
> pas d'evenement, les fonctions sont non bloquantes
> ils faut utiliser un thread
1°) Un thread bloqué en lecture (en attente de données),
2°) Un autre thread qui écrit sur la même socket que celle bloquée par
le thread n° 1,
La fonction socketecrit met 2 à 3 secondes pour s'exécuter.
Si la socket n'est pas bloquée en lecture, aucun problème, socketécrit
s'exécute immédiatement.
Donc, j'aimerai ne pas bloquer la socket et savoir quand il y a une
réception ou une connexion.
pas sur qu'une socket soit partageable entre 2 thread. si tes threads sont en mode automatique, il est possible que windev considere la socket comme une section critique et te bloque.
De toute facon, pour qu'une liaison socket fonctionne correctement, il vaut mieux que quand tu envoi, l'autre en face recoive (hormis pour des tres faible débit style telnet) sinon tu risque de perdre de l'info quand les buffers seront plein. donc AMHA, si c'est possible, essaie de mettre en place un protocole pour savoir a qui le tour de parler, et a qui le tour d'écouter
ca fait quoi ton soft ?
"//" a écrit dans le message de news:
patrice a formulé ce dimanche :
> pas d'evenement, les fonctions sont non bloquantes > ils faut utiliser un thread
1°) Un thread bloqué en lecture (en attente de données), 2°) Un autre thread qui écrit sur la même socket que celle bloquée par le thread n° 1,
La fonction socketecrit met 2 à 3 secondes pour s'exécuter.
Si la socket n'est pas bloquée en lecture, aucun problème, socketécrit s'exécute immédiatement.
Donc, j'aimerai ne pas bloquer la socket et savoir quand il y a une réception ou une connexion.
