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>
 <s41hi0$n3o$1@dont-email.me> <6064b1f3$0$12711$426a74cc@news.free.fr>
 <s42hg5$617$1@dont-email.me> <6064e2da$0$3711$426a74cc@news.free.fr>
 <fantome.forums.tDeContes-A8C875.08062720012022@news.free.fr>
From: DrPi <314@drpi.fr>
In-Reply-To: <fantome.forums.tDeContes-A8C875.08062720012022@news.free.fr>
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.