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 From: Thomas Newsgroups: fr.comp.lang.ada Mail-Copies-To: nobody Subject: Re: GtkAda et multi =?UTF-8?Q?t=C3=A2ches.?= References: <605dabbf$0$12705$426a74cc@news.free.fr> <6064b1f3$0$12711$426a74cc@news.free.fr> <6064e2da$0$3711$426a74cc@news.free.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit User-Agent: MT-NewsWatcher/3.5.3b3 (Intel Mac OS X) Date: Thu, 20 Jan 2022 08:06:28 +0100 Message-ID: Lines: 128 Organization: Guest of ProXad - France NNTP-Posting-Date: 20 Jan 2022 08:06:28 CET NNTP-Posting-Host: 91.175.52.121 X-Trace: 1642662388 news-2.free.fr 3688 91.175.52.121:14286 X-Complaints-To: abuse@proxad.net Bytes: 6933 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é ? :-) -- RAPID maintainer http://savannah.nongnu.org/projects/rapid/