Path: ...!news.mixmin.net!weretis.net!feeder8.news.weretis.net!news.trigofacile.com!usenet-fr.net!agneau.org!nntpfeed.proxad.net!proxad.net!feeder1-1.proxad.net!cleanfeed2-a.proxad.net!nnrp1-1.free.fr!not-for-mail Date: Thu, 20 Jan 2022 18:40:03 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: =?UTF-8?Q?Re=3a_GtkAda_et_multi_t=c3=a2ches=2e?= Content-Language: fr Newsgroups: fr.comp.lang.ada References: <605dabbf$0$12705$426a74cc@news.free.fr> <6064b1f3$0$12711$426a74cc@news.free.fr> <6064e2da$0$3711$426a74cc@news.free.fr> From: DrPi <314@drpi.fr> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Lines: 128 Message-ID: <61e99e74$0$29497$426a74cc@news.free.fr> Organization: Guest of ProXad - France NNTP-Posting-Date: 20 Jan 2022 18:40:04 CET NNTP-Posting-Host: 82.65.30.55 X-Trace: 1642700404 news-3.free.fr 29497 82.65.30.55:50772 X-Complaints-To: abuse@proxad.net Bytes: 7296 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.