Discussion :

[deuzef68]

Bonjour à tous

je développe pour moi une application embarqué sur un Raspberry PI...
Je recherche des idées niveau technique et faisabilité.

Je vous explique...
un daemon charge un fichier de règles au démarrage du système... ce démon utilise ce fichier de règles
pour en déduire des opérations d'éntrées et sorties physique... le daemon dialoguera avec les entrées/sorties
au travers de plugins... qui permet d'avoir un système ouvert par la suite...
ce daemon passe les règles 1 par 1... suivant les règles qui sont vérifiés enclenche des actions...
puis recommence à la première...en permanence...en boucle

sur la même machine un serveur web dialoguera avec le daemon... au travers de sockets... cette partie là
est pour l'instant une étude...
ses actions devraient être de simple commande...du style "Start ou Stop ou Reload ou State" et reçoit une simple réponse du style OK
ou l'état du Daemon... c'est toujours hypothétique...

le soucis qui me taraude et que ce daemon part forcément dans une boucle continue...
comment techniquement "interrompre" la boucle le temps de traiter sur une entrée Sockets
c'est à dire que si le serveur "demande" l'état du daemon au travers d'une sockets...
le daemon stoppe la boucle... répond par sockets au serveur et reprend la boucle là où elle l'a arrêtée...

question: est-ce faisable ? il y a t'il un moyen d'avoir "une interruption" sur une entrée sockets ?
quelqu'un a t'il une idée...
peut être même une autre approche...

J'ai déjà pas mal fouillé le net et google est mon ami... mais je n'ai rien trouvé de très intéressant

Merci d'avance

Fred

[Obsidian]

Bonjour,

En effet, c'est un algo à « boucle principale » tout ce qu'il y a de plus classique.
Si tu travailles sous un unixoïde ou un système POSIX, il faut utiliser l'appel système select() ou un des dérivés de poll().

L'idée générale est de surveiller plusieurs descripteurs de fichiers à la fois et de débloquer dès que l'un d'eux au moins devient disponible, que ce soit en écriture ou en lecture. Il est possible d'ajouter en plus une valeur de timeout pour débloquer systématiquement au bout du délai de grâce.

Ça veut dire que tout ton traitement doit être basé sur la disponibilité ou non de certaines informations, accessibles via des sockets ou des descripteurs de fichiers ordinaires, de façon à pouvoir effectivement rester en attente s'il n'y a rien à faire.

Si réellement, ton programme tourne en permanence et est interrogé occasionnellement, il est effectivement possible d'être interrompu en donnant l'attribut O_ASYNC à ton socket. Tu recevras alors le signal SIGIO s'il y a quelque chose à lire et il t'appartiendra alors de gérer celui-ci correctement. Mais attention : il ne s'agit pas de recevoir un signal par trame ou par caractère et de tout gérer depuis le handler. Ça signifie qu'il faudra dans tous les cas mettre en place une structure au sein de ta boucle principale, qui entrera en fonction quand le handler de signal lèvera un flag.

Enfin, si tu as vraiment un traitement de fond à faire en coulisses et que tu veux assurer un « guichet d'accueil » à l'intention des clients de ton daemon, le plus simple consiste à créer deux threads distincts. L'un pour le travail à faire, l'autre dédié à la communication avec les clients. Mais il est toujours intéressant de savoir faire cela sans y recourir, sur un plan purement algorithmique dans un premier temps, et parce que les threads peuvent ne pas être disponibles du tout sur les systèmes embarqués et les petites architectures.

[deuzef68]

Déjà merci pour la réponse...sympa

Si réellement, ton programme tourne en permanence et est interrogé occasionnellement, il est effectivement possible d'être interrompu en donnant l'attribut O_ASYNC à ton socket. Tu recevras alors le signal SIGIO s'il y a quelque chose à lire et il t'appartiendra alors de gérer celui-ci correctement. Mais attention : il ne s'agit pas de recevoir un signal par trame ou par caractère et de tout gérer depuis le handler. Ça signifie qu'il faudra dans tous les cas mettre en place une structure au sein de ta boucle principale, qui entrera en fonction quand le handler de signal lèvera un flag.

oui effectivement mon programme boucle en permanence pour traiter les entrées et sorties... le serveur web ne fait que ponctuellement des appels pour voir l'état du démon... ou pour recharger une nouvelle base de règles...
le serveur web sert de visu et met en forme les infos pour les présenter de façon plus sympa au user..

j'ai un peu regardé l'attribut O_ASYNC... pour l'instant c'est encore très très nébuleux...
il faudrait que je trouve un exemple d'utilisation... donc retour à google...et je cherche...

Enfin, si tu as vraiment un traitement de fond à faire en coulisses et que tu veux assurer un « guichet d'accueil » à l'intention des clients de ton daemon, le plus simple consiste à créer deux threads distincts. L'un pour le travail à faire, l'autre dédié à la communication avec les clients. Mais il est toujours intéressant de savoir faire cela sans y recourir, sur un plan purement algorithmique dans un premier temps, et parce que les threads peuvent ne pas être disponibles du tout sur les systèmes embarqués et les petites architectures.

pour l'instant un seul client du daemon.. le serveur web...
effectivement j'avais envisagé aussi les threads... un qui est en écoute sur la sockets et qui traine les demandes
et un autre qui fait le traitement principal sur les E/S

bon tout est sur raspberry pi

Fred

[Obsidian]

oui effectivement mon programme boucle en permanence pour traiter les entrées et sorties... le serveur web ne fait que ponctuellement des appels pour voir l'état du démon... ou pour recharger une nouvelle base de règles...

Certes, mais c'est sur ces entrées/sorties qu'il faut se pencher. Comment sont-elles acquises et quel genre de traitement fais-tu dessus ? En particulier, est-ce qu'elles-mêmes auraient le pouvoir de déclencher des interruptions ? En dehors de cela, est-ce que tu les exploites en attaquant directement les ports I/O ou est-ce que tu le fais au travers d'un descripteur de fichier, fichier ouvert en début de traitement ?

Si tu fais du polling pour traiter ces informations, il est quand même intéressant de voir si tu peux éviter de consommer « 100 % du CPU », ne serait-ce que pour avoir une chance de pouvoir entrer en sleep mode quand c'est possible. Sinon, si tu ne fais vraiment que tourner en permanence, tu peux simplement te contenter de passer ton socket en mode non bloquant et d'insérer sa gestion au sein de ta boucle au milieu du reste. Tant qu'il n'y aura rien à lire, l'appel échouera (avec EAGAIN) sans bloquer. Maintenant, il vaut mieux aussi éviter d'effectuer sans arrêt des appels systèmes. Donc O_ASYNC reste la meilleure approche.

[deuzef68]

Certes, mais c'est sur ces entrées/sorties qu'il faut se pencher. Comment sont-elles acquises et quel genre de traitement fais-tu dessus ? En particulier, est-ce qu'elles-mêmes auraient le pouvoir de déclencher des interruptions ? En dehors de cela, est-ce que tu les exploites en attaquant directement les ports I/O ou est-ce que tu le fais au travers d'un descripteur de fichier, fichier ouvert en début de traitement ?

Alors pour préciser... aucune possibilité de déclencher des interruptions sur les E/S... elles ne sont d'ailleurs pas "forcément" directement reliés à la machine sur laquelle tourne le daemon...
Les plugins font drivers entre le daemon et le protocole d'accès aux E/S... demain si tu as envie de relier un autre type d'E/S en protocole particulier
tu écris un plugin... suivant un squelette précisé et tu peux accéder à ses E/S...
un fichier de configuration indiquant à travers quel plugin on peux accéder aux E/S
le fichier de conf indique "quel" plugin...et le plugin indique le "comment"

De plus c'est le daemon qui a "la main" sur les E/S et pas l'inverse
seul le daemon sait "quand" et "quels" E/S à interroger grâce aux règles de la base de règles.
On va dire que lorsque une règle passe dans le démon... le daemon scrute seulement les Entrées qui sont liés à la règle...
puis si les conditions sont valides... alors le daemon contacte la sortie et la positionne dans l'état désiré
1 règle peux avoir comme conditions autant d'entrées que nécessaire mais ne déclenchera au final qu'une seule sortie...

Si tu fais du polling pour traiter ces informations, il est quand même intéressant de voir si tu peux éviter de consommer « 100 % du CPU », ne serait-ce que pour avoir une chance de pouvoir entrer en sleep mode quand c'est possible. Sinon, si tu ne fais vraiment que tourner en permanence, tu peux simplement te contenter de passer ton socket en mode non bloquant et d'insérer sa gestion au sein de ta boucle au milieu du reste. Tant qu'il n'y aura rien à lire, l'appel échouera (avec EAGAIN) sans bloquer. Maintenant, il vaut mieux aussi éviter d'effectuer sans arrêt des appels systèmes.

le soucis est que je ne "maîtrise" pas le temps de traitement sur une règle... pour plusieurs raisons et notamment qu'une règle peut être longue et complexe... je voudrais éviter de perdre le traitement en cours...

par exemple..
imaginons la règle S1 = E1 . E2 . E3 donc la sortie S1 sera à 1 si E1 et E2 et E3 sont toute à 1
jusque là facile

le moteur (daemon) lit la règle...interroge l'entrée E1...ok elle est à 1....interroge l'entrée E2...ok aussi...
top...à ce moment là le serveur interroge le daemon sur son état...

l'idéal serait que le daemon traite "l'interruption" et réponde au serveur...puis reprends
là ou il était et continue la règle...interroge l'entrée E3...elle est ok...alors le daemon envoie l'ordre de mettre S1 à 1

ça serait une bonne utilisation...il peut y en avoir d'autres

mais si j'attends de finir la règle...pour répondre au serveur...bof bof... d'ailleurs si j'attends le temps entre 2 règles
pour scruter s'il y a une demande de la part du serveur... la demande risque à tous les coups d'être perdue...
et le daemon ne répondra pas au serveur
Ce serait idiot aussi de perdre la fin de la règle et passer à la règle suivante pour répondre au serveur...

Donc O_ASYNC reste la meilleure approche.

tu aurais un source...un petit exemple... car je suis un peu dans le brouillard sur le principe