|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Bonjour,
J'utilise un callback de type ClientMessage dans mon application, afin de détecter si il y a eu une déconnexion. Si c'est le cas, dans la fonction callback, je tente de reconnecter l'application puis j'indique via une variable partagée que la commande sybase qui a échouée suite à la déconnexion peut-être relancée. Cependant cela ne fonctionne pas car le callback semble être executé "en parallèle" de la commande sybase, et donc lorsque la variable partagée est testée pour savoir si la commande échouée doit être relancée, le callback n'a pas encore mis à jour cette variable. Existe-t-il un moyen de synchroniser les callback, et d'éviter une exécution parallèle au process ? Merci d'avance |
|
|
00
|
|
|
#2 |
![]() ![]() |
Est-ce qu'il s'agit d'une appli multi-threadée ?
Je ne suis plus tout-à-fait aussi pointu dans la programmation OpenClient que je l'ai été, mais il me semble qu'on ne peut pas appeler ct_connect() depuis un callback. Si mes souvenirs sont bons la technique "approvée" est de mettre un flag dans le callback (ce que tu semble faire) et ensuite tester ce flag en dehors du callback pour recréer la connexion avant de pouvoir relancer la commande qui a planté. Michael
__________________
Michael Peppler Membre de TeamSybase - www.teamsybase.com "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson |
|
|
00
|
|
|
#3 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Merci pour cette réponse rapide.
Non il ne s'agit pas d'une appli multi-thread, cependant en effet je fais appel au ct_connect dans mon callback, en plus du flag. La reconnection se fait bien donc je pense que de ce côté là ça va. Je vais tout de même essayer de faire autrement et de me contenter de flaguer dans le callback et de reconnecter en dehors. Je vais voir ce que ça donne. Merci |
|
|
00
|
|
|
#4 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Malheureusement ça ne fonctionne toujours pas.
Si je détecte une deconnection : - Dans le callback je flag une variable static "disconnect" à 1 - Dans le process qui execute la commande sybase, je check directement après le ct_command, la valeur de "disconnect", mais la variable n'a pas été mise à jour par le callback, cette opération est faite de manière désynchronisé, après... C'est plutôt embêtant comme comportement... |
|
|
00
|
|
|
#5 | ||
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Bon je pense avoir avancé dans mon problème.
D'après ce que j'ai compris, lors d'une déconnection, la notification par le serveur (et donc l'appel du callback associé) a lieu lors de la prochaine tentative de commande sur le serveur. Pour éviter ce comportement, il faut modifier la property CS_ASYNC_NOTIFS et la mettre à true. Avec l'aide de cette commande : Code :
ct_con_props(*connexion, CS_SET, CS_ASYNC_NOTIFS, (CS_VOID*)CS_TRUE, CS_UNUSED, NULL) Voici le code complet de ma fonction de connexion, merci de votre aide ! Code :
|
||
|
|
00
|
|
|
#6 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Ok j'ai trouvé la cause de mon core dump (le CS_TRUE passé dans ct_con_props doit être une adresse sur int).
Une fois la property CS_ASYNC_NOTIFS mis à true, la déconnection est détectée automatiquement et le callback lancé dans la foulée, c'est pas mal du tout. Sauf que cela envoie aussi un signal à mon programme qui se kill tout seul du coup argh ... |
|
|
00
|
|
|
#7 |
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Mon programme se kill car il reçoit un Interrupt System Call (EINTR) de la part de la CTlib...
Ce n'est pas un signal alors je ne sais pas du tout comment ça se catch... |
|
|
00
|
|
|
#8 |
![]() ![]() |
Il doit y avoir un problème entre les notifications asynchrones et le reste de ton programme.
Idéalement il faudrait construire un programme example (aussi petit que possible) qui illustre le problème - cela permettrait probablement de trouver la bonne façon de coder pour arriver à obtenir le comportement que tu cherche. Michael
__________________
Michael Peppler Membre de TeamSybase - www.teamsybase.com "A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson |
|
|
00
|
|
|
#9 | ||||
|
Membre habitué
![]() Inscription : août 2005 Messages : 142 ![]() |
Rectification : en effet je me suis trompé mon programme n'est pas killé en fait, il sort de son plein gré car c'est programmé ainsi.
En fait au moment du EINTR, le programme est en attente de réception d'un message sur une file de message (msgrcv()). Le EINTR provoque la sortie de cette fonction et dans mon programme j'interprète cela comme un erreur grave qui provoque une sortie. Voici les lignes de codes où le EINTR intervient: Code :
De cette manière ? : Code :
Merci d'avance |
||||
|
|
00
|
Copyright © 2000-2012 - www.developpez.com