Re: GtkAda et multi tâches.

Le 20/01/2022 à 08:06, Thomas a écrit :

In article <6064e2da$0$3711$426a74cc@news.free.fr>, DrPi <314@drpi.fr>
wrote:
 

Le 31/03/2021 à 21:11, J-P. Rosen a écrit :

Le 31/03/2021 à 19:31, DrPi a écrit :

Le 31/03/2021 à 12:05, J-P. Rosen a écrit :

Le 26/03/2021 à 10:39, DrPi a écrit :

Je fais des essais avec GtkAda. Mon but est d'afficher des données
reçues par une interface série ou par le réseau. Donc, multi-tâches
obligatoire.
Ce que l'on peut lire sur la page d'aide de GtkAda(1) ne me plait
pas vraiment. Je ne vois pas comment faire un affichage réactif avec
des callbacks 'idle' ou 'timeout'.

 

Jean-Pierre (ou quelqu'un d'autre), y a t'il une bonne solution à ce
problème ?

 

J'ai un programme qui a une interface GTK, un serveur AWS, et une BDD
SQLite... Voilà comment ça marche.
>
Je commence par lancer/initialiser AWS et la base de données.
Ensuite, j'ai une seule tâche qui gère tout ce qui est GTK, et qui
rentre dans la main loop GTK.
>
Ca communique par un FIFO (protégé) de messages donnant à la tâche
GTK ce qu'elle doit afficher. L'astuce, c'est que quand je mets un
message dans le FIFO, j'appelle  Glib.Main.Idle_Add avec la procédure
qui va aller repécher le message et agir en conséquence (et qui
retourne False, comme ça le Idle est débranché jusqu'au prochain
message). => pas de boucle active.
>

>
Intéressant. Je ne pensais pas que l'on pouvait appeler une quelconque
fonction de GtkAda en dehors du thread graphique.
Méthode intéressante. Good job :)

>
Ce que j'ai compris, c'est que la tâche qui appelle Main_Loop est
bloquée en attente d'événement. Idle_Add va créer un événement, avec en
paramètre la procédure à appeler, mais ce sera bien la tâche GTK qui
effectuera l'appel.
>

>
C'est ce que j'ai compris aussi en lisant la doc.

 si Dmitry Kazakov ne lit pas ce fil, je suggère que des que qqn en aura
l'occasion, il lui fasse la suggestion d'intégrer l'astuce de
Jean-Pierre.
 j'ai vérifié sa dernière version, si je ne me trompe pas il en est resté
à un Idle avec une boucle active répétée toutes les 0,2 secondes (par
défaut - on peut choisir le délai).
 si je ne me trompe pas, l'astuce de Jean-Pierre permet,
en plus d'économiser du traitement processeur quand il ne se passe rien,
d'être plus réactif quand il y a un traitement à faire, en le traitant
immédiatement plutôt que d'attendre au max 0,2 s donc en moyenne 0,1 s
pour le faire.
 c'est probablement qqch qui lui a simplement échappé :
je n'ai pas lu la doc aussi soigneusement que Nicolas,
et avant de lire ce fil, je croyais que tout ce qui venait avec le
paquet GtkAda devait impérativement être appelé par la même tache.
  

>

>
Il me vient tout de suite une question : Dans mon application,
beaucoup de messages/seconde peuvent être reçus par le réseau et
transmis au thread graphique. Faut-il une méthode de régulation pour
ne pas submerger GtkAda d'appels à Glib.Main.Idle_Add() ?
Je pose la question, mais ce n'est, à priori, pas bien compliqué à
implémenter. Donc, la question, c'est plus pour la forme.

 

>
Ben, ça créera juste une accumulation de messages dans la file d'attente
de la tâche GTK. Après, c'est juste une question de priorité entre les
tâches. Mais de toute façon, si le producteur produit plus vite que le
consommateur ne peut traiter, il y aura toujours un problème.
>

Tout à fait.
Pour être plus précis, il y a des salves de messages par moments. Une
grosse salve au démarrage et d'autres plus petites par la suite. Dans la
globalité, le débit est faible. Ce sont les salves qui m'inquiètent s'il
y a une limite sur la file d'attente.

 en fait, les taches ça m'intéresse, mais pour l'instant pour moi c'est
encore à l'état de rêves, je ne m'y connais pas assez.
et je ne travaille pas dessus en ce moment.
 il me semble que dans une architecture où chaque couche est bien conçue,
aucun remplissage de tampon ne devrait causer un pb critique,
mais devrait tjr causer la mise en attente du producteur en attendant
que le consommateur ait libéré un peu de place.
 donc amha, c'est ce mécanisme qui doit être peaufiné.
et après, les réglages de priorités et de taille des mémoires tampon,
c'est bien pour l'optimisation, mais ça ne devrais pas avoir d'impact
sur le bon résultat à la fin :-)
  j'ai survolé Gtk.Main.Router parce que je pense bien que j'en aurai
besoin un peu plus tard, mais je n'ai pas creusé à fond.
 on dirait qu'il y a une file d'attente implémentée dans le type
Request_Item, mais qui ne sert qu'avec Gateway.Request_Asynchronous, et
je n'ai pas eu la patience de découvrir dans quels cas de figure c'est
utilisé.
l'usage basique de Request utilise Gateway.Request_Synchronous,
et si je ne me trompe pas, ça n'utilise pas la file d'attente
implémentée dans le type Request_Item, mais uniquement celle du langage
pour les queues sur l'objet protégé qui sont gérées directement par le
compilateur pas par le développeur.
 il faudrait voir comment ça se passe quand une file d'attente de ce type
dépasse les limites prévues : est-ce que ça fait marcher un mécanisme
tel que je l'ai décrit ci-dessus, ou est-ce que ça crash d'une façon ou
d'une autre ?
 

Je ferai des tests et j'adapterai en conséquence.

 qu'est-ce que ça a donné ? :-)
 

J'ai conçu une solution basée sur les indications de Jean-Pierre. Je n'ai pas fait beaucoup de tests mais ça a l'air de bien fonctionner.