J'ai un thread principal (ma UI) qui lance un autre thread "Serveur"
chargé d'écouter sur le réseau. Pour ce faire, j'ai une boucle qui
effectue une lecture blocante et ce indéfiniment.
Comment faire pour que quand l'utilisateur ferme ma UI je puisse fermer
proprement le thread serveur ?
Est-ce que si je fais un Abort ça va marcher ? Comment faire alors pour
terminer proprement mon serveur et fermer convenablement mon socket ?
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
Fred
"Pierre Alexis" a écrit dans le message de news:
Bonjour,
Re-problème qui me turlupine depuis longtemps...
J'ai un thread principal (ma UI) qui lance un autre thread "Serveur" chargé d'écouter sur le réseau. Pour ce faire, j'ai une boucle qui effectue une lecture blocante et ce indéfiniment.
Comment faire pour que quand l'utilisateur ferme ma UI je puisse fermer proprement le thread serveur ?
Est-ce que si je fais un Abort ça va marcher ? Comment faire alors pour terminer proprement mon serveur et fermer convenablement mon socket ?
Bref un problème très courant somme toute ^^
Merci !
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Bonsoir, Donc le serveur ne sert qu'un client ? Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread. Je ne sais pas si ma méthode est la meilleure. Peut-être un spécialiste du réseau nous donnera-t-il son avis ?
"Pierre Alexis" <alexispierre@hotmail.com> a écrit dans le message de news:
um81gIHFFHA.1188@tk2msftngp13.phx.gbl...
Bonjour,
Re-problème qui me turlupine depuis longtemps...
J'ai un thread principal (ma UI) qui lance un autre thread "Serveur"
chargé d'écouter sur le réseau. Pour ce faire, j'ai une boucle qui
effectue une lecture blocante et ce indéfiniment.
Comment faire pour que quand l'utilisateur ferme ma UI je puisse fermer
proprement le thread serveur ?
Est-ce que si je fais un Abort ça va marcher ? Comment faire alors pour
terminer proprement mon serveur et fermer convenablement mon socket ?
Bonsoir,
Donc le serveur ne sert qu'un client ?
Dans une problématique un peu différente (plusieurs clients), j'ai évité les
appels blocants et utilisé un select.
Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des
données, lesquels ont été fermés ...
Cela ne répond pas à ta question directement mais cela permet de sortir
proprement du thread.
Je ne sais pas si ma méthode est la meilleure. Peut-être un spécialiste du
réseau nous donnera-t-il son avis ?
J'ai un thread principal (ma UI) qui lance un autre thread "Serveur" chargé d'écouter sur le réseau. Pour ce faire, j'ai une boucle qui effectue une lecture blocante et ce indéfiniment.
Comment faire pour que quand l'utilisateur ferme ma UI je puisse fermer proprement le thread serveur ?
Est-ce que si je fais un Abort ça va marcher ? Comment faire alors pour terminer proprement mon serveur et fermer convenablement mon socket ?
Bref un problème très courant somme toute ^^
Merci !
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Bonsoir, Donc le serveur ne sert qu'un client ? Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread. Je ne sais pas si ma méthode est la meilleure. Peut-être un spécialiste du réseau nous donnera-t-il son avis ?
Pierre Alexis
Fred a écrit :
Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread.
Comment ?
Merci.
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Fred a écrit :
Dans une problématique un peu différente (plusieurs clients), j'ai évité les
appels blocants et utilisé un select.
Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des
données, lesquels ont été fermés ...
Cela ne répond pas à ta question directement mais cela permet de sortir
proprement du thread.
Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread.
Comment ?
Merci.
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Fred
"Pierre Alexis" a écrit dans le message de news:
Fred a écrit :
Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread.
Comment ?
Merci.
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Comment cela permet de sortir proprement je suppose ? Dans ma classe j'ai tout simplement un booléen qui me sert pour la boucle "infinie" du thread. Lorsque je veux "fermer" mon serveur, je mets ce booléen à faux et je fais un Thread.Join Je n'ai pas le code sous la main et je ne me rappelle plus des détails. On en reparle lundi si tu veux. Si le comment portait sur autre chose, alors je te propose de regarder l'aide sur la méthode select du socket. Je crois qu'il y a un petit exemple. L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire. J'ai regardé ton lien sur les sockets. Si tu as appliqué ce qui est dit j'en déduis que tu as un thread par client (ce que je n'avais pas compris au départ). Dans le principe que j'ai utilisé, il n'y a qu'un Thread, dans la boucle duquel je teste d'abord s'il y a une demande de connexion, auquel cas je réponds en créant un nouveau socket que je mets dans un ArrayList. J'utilise ensuite mon ArrayList avec la méthode select pour obtenir deux nouvelles listes, une avec les sockets qui ont des données en attente que je traite, et une avec les sockets qui ont été fermés (de mémoire). Et je boucle.
"Pierre Alexis" <alexispierre@hotmail.com> a écrit dans le message de news:
42161097.3050408@hotmail.com...
Fred a écrit :
Dans une problématique un peu différente (plusieurs clients), j'ai évité
les appels blocants et utilisé un select.
Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des
données, lesquels ont été fermés ...
Cela ne répond pas à ta question directement mais cela permet de sortir
proprement du thread.
Comment cela permet de sortir proprement je suppose ?
Dans ma classe j'ai tout simplement un booléen qui me sert pour la boucle
"infinie" du thread.
Lorsque je veux "fermer" mon serveur, je mets ce booléen à faux et je fais
un Thread.Join
Je n'ai pas le code sous la main et je ne me rappelle plus des détails. On
en reparle lundi si tu veux.
Si le comment portait sur autre chose, alors je te propose de regarder
l'aide sur la méthode select du socket.
Je crois qu'il y a un petit exemple.
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures
uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
J'ai regardé ton lien sur les sockets. Si tu as appliqué ce qui est dit j'en
déduis que tu as un thread par client (ce que je n'avais pas compris au
départ). Dans le principe que j'ai utilisé, il n'y a qu'un Thread, dans la
boucle duquel je teste d'abord s'il y a une demande de connexion, auquel cas
je réponds en créant un nouveau socket que je mets dans un ArrayList.
J'utilise ensuite mon ArrayList avec la méthode select pour obtenir deux
nouvelles listes, une avec les sockets qui ont des données en attente que je
traite, et une avec les sockets qui ont été fermés (de mémoire). Et je
boucle.
Dans une problématique un peu différente (plusieurs clients), j'ai évité les appels blocants et utilisé un select. Cela permet de savoir (dans une liste de sockets) lesquels ont reçu des données, lesquels ont été fermés ... Cela ne répond pas à ta question directement mais cela permet de sortir proprement du thread.
Comment ?
Merci.
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Comment cela permet de sortir proprement je suppose ? Dans ma classe j'ai tout simplement un booléen qui me sert pour la boucle "infinie" du thread. Lorsque je veux "fermer" mon serveur, je mets ce booléen à faux et je fais un Thread.Join Je n'ai pas le code sous la main et je ne me rappelle plus des détails. On en reparle lundi si tu veux. Si le comment portait sur autre chose, alors je te propose de regarder l'aide sur la méthode select du socket. Je crois qu'il y a un petit exemple. L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire. J'ai regardé ton lien sur les sockets. Si tu as appliqué ce qui est dit j'en déduis que tu as un thread par client (ce que je n'avais pas compris au départ). Dans le principe que j'ai utilisé, il n'y a qu'un Thread, dans la boucle duquel je teste d'abord s'il y a une demande de connexion, auquel cas je réponds en créant un nouveau socket que je mets dans un ArrayList. J'utilise ensuite mon ArrayList avec la méthode select pour obtenir deux nouvelles listes, une avec les sockets qui ont des données en attente que je traite, et une avec les sockets qui ont été fermés (de mémoire). Et je boucle.
Pierre Alexis
Fred a écrit :
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose donc que tu lui définis un "timeout" et que tu le "relances" après chaque timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
Merci et à lundi pour en reparler ;-) !
++
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Fred a écrit :
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures
uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose
donc que tu lui définis un "timeout" et que tu le "relances" après
chaque timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose donc que tu lui définis un "timeout" et que tu le "relances" après chaque timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
Merci et à lundi pour en reparler ;-) !
++
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Fred
"Pierre Alexis" a écrit dans le message de news:
Fred a écrit :
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose donc que tu lui définis un "timeout" et que tu le "relances" après chaque timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
Merci et à lundi pour en reparler ;-) !
++
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Bonsoir, Oui, le select est "bloquant" dans le sens où tu lui spécifies un nombre de microsecondes d'attente avant de retourner. Quand tu parlais d'appel bloquant, je suppose que tu faisais allusion au fait que l'exécution de ton thread est figée si aucune donnée n'est disponible en lecture, d'où la nécessité du abort. Ce n'est jamais le cas avec le select. Le délai n'est pas un timeout, mais bien un temps de scrutation pendant lequel le select prend en compte les éventuels changements.
"Pierre Alexis" <alexispierre@hotmail.com> a écrit dans le message de news:
OUSeVGnFFHA.3888@TK2MSFTNGP12.phx.gbl...
Fred a écrit :
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les
lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose donc
que tu lui définis un "timeout" et que tu le "relances" après chaque
timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
Bonsoir,
Oui, le select est "bloquant" dans le sens où tu lui spécifies un nombre de
microsecondes d'attente avant de retourner. Quand tu parlais d'appel
bloquant, je suppose que tu faisais allusion au fait que l'exécution de ton
thread est figée si aucune donnée n'est disponible en lecture, d'où la
nécessité du abort. Ce n'est jamais le cas avec le select. Le délai n'est
pas un timeout, mais bien un temps de scrutation pendant lequel le select
prend en compte les éventuels changements.
L'idée c'est de ne plus avoir d'appels blocants. Donc appeler les lectures uniquement lorsque l'on est sûr qu'il y a quelquechose à lire.
Certes, mais alors c'est ton "Select" qui est bloquant... Je suppose donc que tu lui définis un "timeout" et que tu le "relances" après chaque timeout en ayant vérifié la valeur de ton booléen. J'ai juste ? :-p
Merci et à lundi pour en reparler ;-) !
++
-- Pierre ALEXIS Courriel : FAQ Visual Basic : http://faq.vb.free.fr/
Bonsoir, Oui, le select est "bloquant" dans le sens où tu lui spécifies un nombre de microsecondes d'attente avant de retourner. Quand tu parlais d'appel bloquant, je suppose que tu faisais allusion au fait que l'exécution de ton thread est figée si aucune donnée n'est disponible en lecture, d'où la nécessité du abort. Ce n'est jamais le cas avec le select. Le délai n'est pas un timeout, mais bien un temps de scrutation pendant lequel le select prend en compte les éventuels changements.
