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 <fantome.forums.tDeContes@free.fr.invalid>
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> <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>
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: <fantome.forums.tDeContes-A8C875.08062720012022@news.free.fr>
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/