Discussion :

[franckcl]

bonjour,

J'utilise la classe TClientSocket (dans System.Win.ScktComp) avec laquelle je suis confronté à un problème lorsque je détruit l'objet.

Je créé le socket par:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 ClientSocket1        := TClientSocket.Create(nil);
 ClientSocket1.OnError:= ClientSocket1Error;
 ClientSocket1.Host := '192.168.0.1';
 ClientSocket1.Port := 502;
 ClientSocket1.Active:=true;

Je le détruit par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
ClientSocket1.Close;
ClientSocket1.free;

Dans mon cas l'adresse IP n'existe pas et donc lorsque je détruit l'objet, le thread qui a été créé par l'API n'est pas détruit et alors une exception apparait quelques secondes après la destruction du socket :

Exception 'first chance' à $00000000. Classe d'exception $C0000005 avec un message 'access violation at 0x00000000: read of address 0x00000000'. Processus MyAPP.exe (5452)


Si quelqu'un a une idée pour détruire le thread du socket en même temps qu'on détruit le socket ??

En revanche je n'ai pas de problème lorsque je quitte mon application.
Merci
Franck

[ShaiLeTroll]

une exception apparait quelques secondes après la destruction du socket

une VA en 00000000, typique d'un objet nil
Probablement le membre privé de type TClientWinSocket interne au TClientSocket qui a été libéré, quoi qu'en lisant le code de Destroy, il n'y a pas d'affectation à nil

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
if Assigned(ClientSocket1) then
begin
  ClientSocket1.OnError := nil;
  if ClientSocket1.Active then
    ClientSocket1.Close();
  ClientSocket1.Free();
end;

Si quelqu'un a une idée pour détruire le thread du socket en même temps qu'on détruit le socket ??

ClientType est par défaut à ctNonBlocking, cela utilise des variantes asynchrones des API, j'ignore si l'on peut dire que cela crée un thread mais ce n'est pas effectivement éloigné en terme de comportement !

En réalité, comme tu es en mode ctNonBlocking, à mon avis, tu dois attendre la notification par OnError ou OnConnect pour poursuivre !

Peux-tu différer la destruction ?
Par exemple, dans le OnError, utiliser un PostMessage personnalisé pour libérer l'objet (un peu comme le Release d'une TForm, version différée du Free)

Le TServerSocket fonctionne ainsi avec son DeferFree\CM_DEFERFREE mais pas le TClientSocket

Cette VA apparait-elle qu'en Notification (first chance) puis une seconde fois en vrai Exception ?
Ce n'est peut-être qu'un signalement par le déboggueur !

Pense que le TClientSocket est fourni pas compatibilité avec Delphi 6, normalement le composant c'est TTCPClient ou TIdTCPClient, l'unité ScktComp a été dépréciée en Delphi 7 (depuis semble que l'on ne sache plus vraiment si ils sont considérés comme bon ou pas, leurs absences de la Palette amène un fort doute )

[franckcl]

toujours le même qui répond...merci ShaiLeTroll
Je viens d'essayer ton code mais ça ne change rien, j'avais déjà essayé de mettre le OnError à nil.
J'ai essayé en release et si je le lance depuis l'IDE alors j'ai ce même message puis si je lance l'exécutable directement depuis windows, alors l'application se fige complêtement. (obligé de tuer la tâche)

Il doit bien y avoir un moyen pour tuer le thread qui a été lancé par l'API et qui tourne en fond !

[tourlourou]

Y a-t-il un TimeOut à respecter avant de détruire ? Mais il devrait déclencher un OnError, je suppose.

[franckcl]

Oui, Il y a un TimeOut, la fonction OnError est appellée environ 20 secondes après l'affectation de ClientSocket1.Active:=true
Le problème est que lorsqu'arrive ce callback, l'objet est détruit car je ne l'utilise plus. Je ne peux pas me permettre d'attendre ce temps avant de le détruire. Je souhaiterai stopper le thread ou mettre fin à la connexion avant ce temps. En plus, je ne sais pas si l'adresse IP en question est valide ou non. Si elle est valide, il n'y a pas de problème puisque OnError n'est pas appelée.
Et je ne sais même pas si un thread est en cours, c'est d'autant plus gênant que je ne peux pas le gérer.

[franckcl]

Un nouvel indice à mon problème.
Ce que je n'ai pas dit c'est que l'activation du socket est appellé par un thread:

ClientSocket1.Active:=true; // appellé par un thread

Ce thread appelle cette fonction régulièrement tant que la connexion n'est pas active (par exemple, en attendant la mise sous tension du serveur).

J'ai essayé d'appeler cette fonction par un timer et je n'ai pas de problème.

Mais bien sur il me faut absolument le lancer via le thread donc problème !

[ShaiLeTroll]

Je ne peux pas me permettre d'attendre ce temps avant de le détruire.

C'est une erreur !
Si tu conserves ton code en ctNonBlocking, il te suffit d'encapsuler le TClientSocket dans un ton propre objet

Cet objet contient un TThread et un pool de TClientSocket, c'est je suppose ton TMySocket mais j'ai l'impression que tu lances plusieurs TMySocket alors que c'est lui qui devrait te fournir cette souplesse de connexion !

A voir ton code, tes objets semblent très imbriqués les uns dans les autres avec MyLog, MyScheduler, je préfère au possible utiliser des Events pour les notifications et des propriétés pour le paramétrage pour avoir un faible couplage !

Lorsqu'une action utilisateur rend cet la connexion obsolète, tu ne le libère pas immédiatement, tu appelles juste un Close, tu attends l'event OnError, OnConnect ou OnDisconnect pour passer à l'étape suivante

Au lieu de gérer un seul socket, tu gères un pool de socket
Ainsi lors que relance une nouvelle connexion ton objet Close le Socket en cours et le laisse en vie le temps qu'il soit dans un état "propre", et crée un nouvel objet

Tu confonds ce que l'on "affiche à l'utilisateur" et ce que l'on fait réellement !
Tu peux faire croire ce que tu veux à ton utilisateur tout en étant rigoureux dans ton code

Il faut qu'on puisse détruire le socket à tout moment. J'utilise une interface graphique, l'utilisateur peut glisser des sockets les configurer et les démarrer quand il veut avec toute la souplesse d'un port de com série. Les déconnexion doivent être gérées et la liaison rétabli automatiquement au plus vite.

En utilisant des threads séparés, il ne devrait y avoir aucun problème !
tu peux "déclarer un socket" comme obsolète, tu le laisse vivre sa vie, si lors du OnConnect ou du OnError, il est voit qu'il a été annulé, il se ferme tout seul et proprement !

Pendant ce temps, tu peux lance un autre objet qui lui prendra la main !

Ton code à mon avis laisse trainer de la merde dans les API Windows, avoir CallBack\Message des Api WSA qui provoque un OnError sur un objet libéré est vraiment le signe d'un gros problème, preuve que Windows gère encore des Handles qui ne devrait plus être là !