Page 3 sur 5

Re: télémaintenance sur ce process lancé au démarrage

Posté : dim. 8 sept. 2019 22:35
par cbalo
Oui, bien sur c'est possible, avec un service dédié à ça.

Re: télémaintenance sur ce process lancé au démarrage

Posté : lun. 9 sept. 2019 20:47
par Bud Spencer
Ce n’est pas un service. Si c’était le cas, il ni aurrait aucune redirection de sortie ...

Re: télémaintenance sur ce process lancé au démarrage

Posté : lun. 9 sept. 2019 21:14
par cbalo
C'est pour ça que la classe est nommée "service" et qu'elle contient une boucle inifnie..... Je sors

Re: télémaintenance sur ce process lancé au démarrage

Posté : mar. 10 sept. 2019 09:59
par Bud Spencer
cbalo a écrit :
lun. 9 sept. 2019 21:14
C'est pour ça que la classe est nommée "service"
Alors déjà, il ni aucune class dans ce code, il y juste des procédures. Si tu veux savoir ce qu’est une class et comment cela se met en œuvre, tu peux jeter un coup d’œil ici, ou j’ai fait une démonstration simpliste et pas à pas de la mutation d’un programme qui s’exécute de façon linaire vers son équivalent en paradigme orienté objet. Ici il n’y a que 2 procédures que j’ai volontairement appelées ‘service’ et ‘console’ pour bien différencié ce qui est exécuté par la première instance démarrée et les suivantes, tout ça pour rendre le code le plus explicite possible tout en restant dans le contexte du sujet.

Ce code reflète juste les 2 notions que j’avais mis en avant dans ma première réponse et qui n’avait pas été comprises, à savoir :

Comment faire en sorte qu’un même code ait un comportement diffèrent suivant s’il est la première instance démarrée ou pas.
Comment passer des commandes a un processus qui ne rend pas la main (pour qu’elle que raison que ce soit et dans le contexte du sujet, parce qu’il tourne en tache de fond ou ‘EN TANT QUE’ service).

Comment ça marche :
Si c’est la première instance du programme qui démarre, le fichier pipe n’existe pas, le programme créé donc ce fichier et exécute la procédure service().

Si on démarre une nouvelle instance , le fichier pipe existe, c‘est donc la procédure console() qui est exécutée.

La procédure service() tourne et chaque tours elle relève le contenu du pipein et elle l’interprète s'il y a une commande qui correspond à une tâche qui lui est programmée (ici la commande raz).

La procédure console() ne fait qu’écrire dans le pipe la (les) commande passée en paramètre puis se termine.

Si j’ai laissé tout ça dans une boucle, c’est juste pour fournir un exemple le plus simple possible (puisque l’on est censé ne s’adresser qu’a des débutants).

A titre d'information, cette méthode est très souvent utilisée en python pour pallier à ses carences en terme de multithreading. Au besoin, le processus est forké et l'échange de donnée père<->enfant se fait par ipc et principalement avec cette méthode de fichier pipe pour les débutants.

Re: télémaintenance sur ce process lancé au démarrage

Posté : mar. 10 sept. 2019 17:33
par cbalo
Exact, c'est une fonction : me culpa : lu trop vite et quand je créé ce genre de chose, j'utilise systématiquement des objets.
N'empêche elle s'appelle service: rigolo et c'est une boucle infinie.

Re: télémaintenance sur ce process lancé au démarrage

Posté : mar. 10 sept. 2019 21:20
par Bud Spencer
cbalo a écrit :
mar. 10 sept. 2019 17:33
..quand je créé ce genre de chose, j'utilise systématiquement des objets.
C’est bien ça. Et tu le fais avec des fonctions qui ne retourne rien ou avec des procédures qui retournent des class ? Perso je ne suis pas trop fan des services infinis qui génèrent des boucles


(Au point où on en est …)

Re: télémaintenance sur ce process lancé au démarrage

Posté : ven. 27 sept. 2019 13:15
par cbalo
Ah, jamais de boucle ?
Comment tu ferais un service d'echange de données entre TCP et rs232 sans boucle infinie ????
Évidement il y a du try except dedans et évidement il y a une fonction d'arrêt pour systemd, évidement on fait en sorte de ne pas surcharger le cpu.Mais faut une boucle infinie.

Re: télémaintenance sur ce process lancé au démarrage

Posté : ven. 27 sept. 2019 18:04
par Artemus24
Salut cbalo.

N'as-tu jamais entendu parlé de la gestion des interruptions ?

@+

Re: télémaintenance sur ce process lancé au démarrage

Posté : sam. 28 sept. 2019 00:03
par Bud Spencer
Déjà soyons clair. Ca :
Bud Spencer a écrit : C’est bien ça. Et tu le fais avec des fonctions qui ne retourne rien ou avec des procédures qui retournent des class ? Perso je ne suis pas trop fan des services infinis qui génèrent des boucles
(Au point où on en est …)
C’est une pure caricature de rien qui ne veut rien dire et qui n’a ni queue ni tête. J’espère au moins que certains l’on compris, sinon, c’est grave, très grave. J’avais écrit ca par exaspération de voir que n’importe qui pouvait écrire n’importe quelle conneries (et le mot est bien mesuré) sans que personne ne dise rien. C’est parfois limite à penser qu’il y a ici un véritable complot pour empêcher les débutants de progresser.
Bref , soyons zen ….
cbalo a écrit :
ven. 27 sept. 2019 13:15
Comment tu ferais un service d'echange de données entre TCP et rs232 sans boucle infinie ????
Comme cela doit etre fait pour etre performant, c’est-à-dire en cloisonnant les entrées/sorties et utilisant des évènements. Ce n’est pas forcément facile pour tout le monde, je l’admets, mais une fois de plus, c’est l'énoncé du problème qui rend les choses compliquées.
cbalo a écrit :
ven. 27 sept. 2019 13:15
Évidement il y a du try except dedans et évidement il y a une fonction d'arrêt pour systemd, évidement on fait en sorte de ne pas surcharger le cpu.Mais faut une boucle infinie.
Non. Toi tu utilises une boucle infinie parce que tu ne sais pas faire autrement, mais ça ne signifie pas que c’est la seule et encore moins la bonne méthode. Tous les codes en while true qui sortent sur des exceptions que tu trouves sur le net ne sont que des exemples soit pour débutant ou alors juste pour démontrer ce qui se trouve à l’interieur de la boucle, mais en aucun cas des solutions à prendre pour argent comptant dans leurs intégralités. Tu peux te contenter de ca pour ‘bricoler une bricole’ qui ne fait pas grand-chose, mais si tu en restes à ça, tu ne seras jamais capable d’écrire un vrai programme et tu ne cesseras de te demander comment faire à chaque fois que tu auras une idée (rassure toi, on est tous passé par là, sauf que pour certains, cela fait très très longtemps…).
Artemus24 a écrit : N'as-tu jamais entendu parlé de la gestion des interruptions ?
Attention avec les mots utilisés Artémus. Une interruption est bloquante (elle interrompt). Si tu écris une évaluation dans une procédure et que cette évaluation te renvois à une série d’instruction (dans l’évaluation ou dans une autre procédure), c’est une interruption. Pendant l’exécution des instructions conditionnées par l’évaluation, ta procédure appelante est arrêtée (Interrompue pour utiliser le terme exact). L’autre méthode (à laquelle je pense que tu voulais faire allusion), c’est la gestion d’évènement. Si tu écris une procédure qui déclenche des évènements, c’est complétement différent. A chaque condition voulue, ta procédure émet un signal mais elle ne s’arrête pas (cas d’un timer par exemple) et les abonnés qui traitent les évènements sont non bloquants pour la procédure d’appel. On parle là de programmation évènementielle et ça, c’est vachement plus rigolo et efficace.

Re: télémaintenance sur ce process lancé au démarrage

Posté : sam. 28 sept. 2019 10:06
par Artemus24
Salut Bud Spencer.

Quand tu dis :
Bud Spencer a écrit :Perso je ne suis pas trop fan des services infinis qui génèrent des boucles
Je suis entièrement d'accord ! C'est une mauvaise façon de programmer.
Mettre une boucle infinie dans un programme, cela revient à ne pas connaitre les possibilités qu'un système comme Debian peut offrir.
Par exemple, faire usage de la crontab, pour déclencher périodiquement le traitement.
Bud Spencer a écrit :J’avais écrit ça par exaspération de voir que n’importe qui pouvait écrire n’importe quelle conneries (et le mot est bien mesuré) sans que personne ne dise rien.
Mais que veux-tu dire sur ce genre de connerie ? Je préfère m'abstenir que de rentrer dans une polémique sans fin.
Juste parce que certains ne savent pas programmer correctement.
Bud Spencer a écrit :Tous les codes en while true qui sortent sur des exceptions que tu trouves sur le net ne sont que des exemples soit pour débutant ou alors juste pour démontrer ce qui se trouve à l'intérieur de la boucle, mais en aucun cas des solutions à prendre pour argent comptant dans leurs intégralités.
C'est pourquoi dans mon exemple sur les leds & interrupteurs, j'ai préféré mettre un timer en remplacement d'une stupide boucle infinie.
Bud Spencer a écrit :L’autre méthode (à laquelle je pense que tu voulais faire allusion), c’est la gestion d'événement.
C'est encore autre chose, la gestion des événements.

Je pensais bien à la gestion des interruptions :
--> https://fr.wikipedia.org/wiki/Interrupt ... ormatique)
En informatique, une interruption est une suspension temporaire de l'exécution d'un programme informatique par le microprocesseur afin d'exécuter un programme prioritaire (appelé service d'interruption).
C'est bien cette idée que j'avais en tête.
Le microprocesseur arrête de faire ce qu'il est en train de faire, en faisant une sauvegarde du contexte avant l'arrêt du traitement.
Le traitement prioritaire s'exécute jusqu'au bout, sans être interrompu.
Puis on restaure le contexte et on poursuit le traitement qui a été arrêté, à cause de cette interruption.

Je pensais à une cause externe, comme il est indiqué dans le lien que j'ai donné :
Dans son acception la plus stricte, le terme ne désigne que des interruptions dont l'exécution est provoquée par des causes externes au programme
Le cas le plus fréquent est la gestion des entrées/sortie.
Je pense que c'est le cas dont voulait souligner "cbalo" avec "un service d'échange de données entre TCP et rs232".
Il n'y a pas de boucle infinie, juste une mise en attente et une interruption quand une donnée se présente.
Sinon, le traitement consommerait énormément de temps CPU, juste pour attendre qu'une hypothétique donnée arrive.

La programmation événementielle, je pense, est plutôt une gestion interne à un traitement.
Des variables qui peuvent changer d'état à un instant donnée.
Je vois cela comme deux traitements qui fonctionnent en parallèle.
L'un vient alimenter des variables en continue.
L'autre se déclenche quand il y a un changement d'état dans l'une de ces variables.

@+