Bonjour,
sur le site supinfo j'ai étudié le cours sur les sockets multi clients.
Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas
vraiment detaillée et qui pose des problemes dans mon appli.
En fait lors d'une boucle do while l'appli se met en standby , elle ne sort
plus de cette boucle, et si j'utilise la propriete bloquante = false j'ai un
message d'erreur du style :
Une opération non bloquante sur un socket n'a pas pu être achevée
immédiatement
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
S. B
Bonjour,
Le principe de la socket bloquante est simple. Il faut que ton unité de traitement soit dans un thread à part afin que tu puisse sérialiser les opérations sans avoir à te soucier de la vie des autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et c'est pour ca que par défaut les sockets fonctionnent en mode bloquant. En revanche la gestion du multi-thread ajoute un niveau de complexité non négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes fonctionnent de façon transparente. Alors que toute opération bloquante revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu demande ne peut pas être réalisées sans attendre. Il te faut donc gérer cela pour continuer ton traitement et revenir effectuer l'opération plus tard.
Le choix du mode de programmation entre les deux mode est entièrement tiens, il n'y a (à ma connaisssance) pas de différence de fonctionnement autres. En revanche ton code sera organisé de façon complètement différente, en fonction de la solution retenue. Dans le cas ou tu passes dans la solution non bloquante, tu pourras choisir de gérer l'ordonnancement des traitements entre les différentes sockets, alors que dans la version multi-thread ca sera à priori géré par l'OS. Pour pouvoir faire du multi-thread, il te faut un OS et un environnement de développement qui supporte le multithread. Dans le cas ou tu utilise la solution non-bloquante, il te faudra mettre en place une "pompe" qui permettra de lire le contenu de test sockets sans avoir à faire de l'attente active.
Bon courage.
SBS
"Laurent HOUTANT" a écrit dans le message de news:
Bonjour, sur le site supinfo j'ai étudié le cours sur les sockets multi clients. Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas vraiment detaillée et qui pose des problemes dans mon appli. En fait lors d'une boucle do while l'appli se met en standby , elle ne sort plus de cette boucle, et si j'utilise la propriete bloquante = false j'ai un message d'erreur du style : Une opération non bloquante sur un socket n'a pas pu être achevée immédiatement
je vous remercie pour votre aide ,
Frederic
Bonjour,
Le principe de la socket bloquante est simple.
Il faut que ton unité de traitement soit dans un thread à part afin que tu
puisse sérialiser les opérations sans avoir à te soucier de la vie des
autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et c'est
pour ca que par défaut les sockets fonctionnent en mode bloquant. En
revanche la gestion du multi-thread ajoute un niveau de complexité non
négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes
fonctionnent de façon transparente. Alors que toute opération bloquante
revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu
demande ne peut pas être réalisées sans attendre. Il te faut donc gérer cela
pour continuer ton traitement et revenir effectuer l'opération plus tard.
Le choix du mode de programmation entre les deux mode est entièrement tiens,
il n'y a (à ma connaisssance) pas de différence de fonctionnement autres. En
revanche ton code sera organisé de façon complètement différente, en
fonction de la solution retenue.
Dans le cas ou tu passes dans la solution non bloquante, tu pourras choisir
de gérer l'ordonnancement des traitements entre les différentes sockets,
alors que dans la version multi-thread ca sera à priori géré par l'OS. Pour
pouvoir faire du multi-thread, il te faut un OS et un environnement de
développement qui supporte le multithread. Dans le cas ou tu utilise la
solution non-bloquante, il te faudra mettre en place une "pompe" qui
permettra de lire le contenu de test sockets sans avoir à faire de l'attente
active.
Bon courage.
SBS
"Laurent HOUTANT" <aretirer.fr.bal@wanadoo.fr.nospam> a écrit dans le
message de news: e7Iym4F8FHA.132@TK2MSFTNGP15.phx.gbl...
Bonjour,
sur le site supinfo j'ai étudié le cours sur les sockets multi clients.
Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas
vraiment detaillée et qui pose des problemes dans mon appli.
En fait lors d'une boucle do while l'appli se met en standby , elle ne
sort plus de cette boucle, et si j'utilise la propriete bloquante = false
j'ai un message d'erreur du style :
Une opération non bloquante sur un socket n'a pas pu être achevée
immédiatement
Le principe de la socket bloquante est simple. Il faut que ton unité de traitement soit dans un thread à part afin que tu puisse sérialiser les opérations sans avoir à te soucier de la vie des autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et c'est pour ca que par défaut les sockets fonctionnent en mode bloquant. En revanche la gestion du multi-thread ajoute un niveau de complexité non négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes fonctionnent de façon transparente. Alors que toute opération bloquante revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu demande ne peut pas être réalisées sans attendre. Il te faut donc gérer cela pour continuer ton traitement et revenir effectuer l'opération plus tard.
Le choix du mode de programmation entre les deux mode est entièrement tiens, il n'y a (à ma connaisssance) pas de différence de fonctionnement autres. En revanche ton code sera organisé de façon complètement différente, en fonction de la solution retenue. Dans le cas ou tu passes dans la solution non bloquante, tu pourras choisir de gérer l'ordonnancement des traitements entre les différentes sockets, alors que dans la version multi-thread ca sera à priori géré par l'OS. Pour pouvoir faire du multi-thread, il te faut un OS et un environnement de développement qui supporte le multithread. Dans le cas ou tu utilise la solution non-bloquante, il te faudra mettre en place une "pompe" qui permettra de lire le contenu de test sockets sans avoir à faire de l'attente active.
Bon courage.
SBS
"Laurent HOUTANT" a écrit dans le message de news:
Bonjour, sur le site supinfo j'ai étudié le cours sur les sockets multi clients. Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas vraiment detaillée et qui pose des problemes dans mon appli. En fait lors d'une boucle do while l'appli se met en standby , elle ne sort plus de cette boucle, et si j'utilise la propriete bloquante = false j'ai un message d'erreur du style : Une opération non bloquante sur un socket n'a pas pu être achevée immédiatement
je vous remercie pour votre aide ,
Frederic
Laurent HOUTANT
merci, je vais mediter
fred "S. " a écrit dans le message de news: 4384d76d$0$13082$
Bonjour,
Le principe de la socket bloquante est simple. Il faut que ton unité de traitement soit dans un thread à part afin que tu puisse sérialiser les opérations sans avoir à te soucier de la vie des autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et c'est pour ca que par défaut les sockets fonctionnent en mode bloquant. En revanche la gestion du multi-thread ajoute un niveau de complexité non négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes fonctionnent de façon transparente. Alors que toute opération bloquante revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu demande ne peut pas être réalisées sans attendre. Il te faut donc gérer cela pour continuer ton traitement et revenir effectuer l'opération plus tard.
Le choix du mode de programmation entre les deux mode est entièrement tiens, il n'y a (à ma connaisssance) pas de différence de fonctionnement autres. En revanche ton code sera organisé de façon complètement différente, en fonction de la solution retenue. Dans le cas ou tu passes dans la solution non bloquante, tu pourras choisir de gérer l'ordonnancement des traitements entre les différentes sockets, alors que dans la version multi-thread ca sera à priori géré par l'OS. Pour pouvoir faire du multi-thread, il te faut un OS et un environnement de développement qui supporte le multithread. Dans le cas ou tu utilise la solution non-bloquante, il te faudra mettre en place une "pompe" qui permettra de lire le contenu de test sockets sans avoir à faire de l'attente active.
Bon courage.
SBS
"Laurent HOUTANT" a écrit dans le message de news:
Bonjour, sur le site supinfo j'ai étudié le cours sur les sockets multi clients. Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas vraiment detaillée et qui pose des problemes dans mon appli. En fait lors d'une boucle do while l'appli se met en standby , elle ne sort plus de cette boucle, et si j'utilise la propriete bloquante = false j'ai un message d'erreur du style : Une opération non bloquante sur un socket n'a pas pu être achevée immédiatement
je vous remercie pour votre aide ,
Frederic
merci, je vais mediter
fred
"S. B@RTHES" <nomail@nomail.com> a écrit dans le message de news:
4384d76d$0$13082$636a15ce@news.free.fr...
Bonjour,
Le principe de la socket bloquante est simple.
Il faut que ton unité de traitement soit dans un thread à part afin que tu
puisse sérialiser les opérations sans avoir à te soucier de la vie des
autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et
c'est pour ca que par défaut les sockets fonctionnent en mode bloquant. En
revanche la gestion du multi-thread ajoute un niveau de complexité non
négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes
fonctionnent de façon transparente. Alors que toute opération bloquante
revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu
demande ne peut pas être réalisées sans attendre. Il te faut donc gérer
cela pour continuer ton traitement et revenir effectuer l'opération plus
tard.
Le choix du mode de programmation entre les deux mode est entièrement
tiens, il n'y a (à ma connaisssance) pas de différence de fonctionnement
autres. En revanche ton code sera organisé de façon complètement
différente, en fonction de la solution retenue.
Dans le cas ou tu passes dans la solution non bloquante, tu pourras
choisir de gérer l'ordonnancement des traitements entre les différentes
sockets, alors que dans la version multi-thread ca sera à priori géré par
l'OS. Pour pouvoir faire du multi-thread, il te faut un OS et un
environnement de développement qui supporte le multithread. Dans le cas ou
tu utilise la solution non-bloquante, il te faudra mettre en place une
"pompe" qui permettra de lire le contenu de test sockets sans avoir à
faire de l'attente active.
Bon courage.
SBS
"Laurent HOUTANT" <aretirer.fr.bal@wanadoo.fr.nospam> a écrit dans le
message de news: e7Iym4F8FHA.132@TK2MSFTNGP15.phx.gbl...
Bonjour,
sur le site supinfo j'ai étudié le cours sur les sockets multi clients.
Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas
vraiment detaillée et qui pose des problemes dans mon appli.
En fait lors d'une boucle do while l'appli se met en standby , elle ne
sort plus de cette boucle, et si j'utilise la propriete bloquante = false
j'ai un message d'erreur du style :
Une opération non bloquante sur un socket n'a pas pu être achevée
immédiatement
fred "S. " a écrit dans le message de news: 4384d76d$0$13082$
Bonjour,
Le principe de la socket bloquante est simple. Il faut que ton unité de traitement soit dans un thread à part afin que tu puisse sérialiser les opérations sans avoir à te soucier de la vie des autres threads.
C'est comme ca que fonctionnent la plupart des programmes sous Unix et c'est pour ca que par défaut les sockets fonctionnent en mode bloquant. En revanche la gestion du multi-thread ajoute un niveau de complexité non négligeable.
Quand tu passe en mode non bloquant, toutes les opérations non bloquantes fonctionnent de façon transparente. Alors que toute opération bloquante revient avec une erreur E_WOULDBLOCK t'indiquant que l'opération que tu demande ne peut pas être réalisées sans attendre. Il te faut donc gérer cela pour continuer ton traitement et revenir effectuer l'opération plus tard.
Le choix du mode de programmation entre les deux mode est entièrement tiens, il n'y a (à ma connaisssance) pas de différence de fonctionnement autres. En revanche ton code sera organisé de façon complètement différente, en fonction de la solution retenue. Dans le cas ou tu passes dans la solution non bloquante, tu pourras choisir de gérer l'ordonnancement des traitements entre les différentes sockets, alors que dans la version multi-thread ca sera à priori géré par l'OS. Pour pouvoir faire du multi-thread, il te faut un OS et un environnement de développement qui supporte le multithread. Dans le cas ou tu utilise la solution non-bloquante, il te faudra mettre en place une "pompe" qui permettra de lire le contenu de test sockets sans avoir à faire de l'attente active.
Bon courage.
SBS
"Laurent HOUTANT" a écrit dans le message de news:
Bonjour, sur le site supinfo j'ai étudié le cours sur les sockets multi clients. Je butte néanmoins sur la notion d'operation bloquante, qui n'est pas vraiment detaillée et qui pose des problemes dans mon appli. En fait lors d'une boucle do while l'appli se met en standby , elle ne sort plus de cette boucle, et si j'utilise la propriete bloquante = false j'ai un message d'erreur du style : Une opération non bloquante sur un socket n'a pas pu être achevée immédiatement
