Discussion :

[john.fender]

Bonjour,

connaissez vous une commande permettant de lancer des commandes, des executables ou des scripts en multithreadé (une tâche par script en charge de capturer exit code, stdout, std err), hors vbs ?

Merci,

john.

[minnesota]

salut

lancer des commandes, des executables ou des scripts en multithreadé

Ça n'a pas de sens ce que tu dis.
Ma fois, tu peux les paralléliser si ça te chante et dans ce cas, la commande start est suffisante.

[john.fender]

Disons que tu ne comprends pas ce que j'écris, ce qui est différent. Je vais essayer d'être plus clair :

start lance un processus puis attends le code retour si demandé, donc on est dans un cadre monothread, une tâche un processus : la console est bloqué, attendant l'exit de la commande.

Si avec un equivalent de la commande Start quelconque, tu lances toutes tes commandes et tu as la possibilité pour chaque commande lancée de consulter ensuite ce qu'elle renvoies (commande finie ou non, code retour...), tu obtiens un start Multithread.

C'est ma question : es-ce que ça existe, hors VBS.

[minnesota]

Disons que tu ne comprends pas ce que j'écris, ce qui est différent.

Elle est bonne, celle-là.

Si avec un equivalent de la commande Start quelconque, tu lances toutes tes commandes et tu as la possibilité pour chaque commande lancée de consulter ensuite ce qu'elle renvoies (commande finie ou non, code retour...),

un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
start cmd /k ta_commande
start cmd /k ou_ton_script
start cmd /k ou_ton_programme

peut faire ce que tu veux.

[john.fender]

Non, ce que tu m'écris c'est du multiprocessus, monothread....

Pour t'aider à comprendre, pose toi la question suivante : comment je fais pour savoir l'état de mes tâches, stdout,stderr et exit code, à tout moment.

Avec ta méthode tu lance des processus différent en parallèle mais c'est tout. Rien en te relies lus aux cmds que tu lances. Si c'était des threads, tu pourrais interroger l'état de chaque cmd dans ton programme principal.

[minnesota]

Ben un thread, dans son fonctionnement n'est pas si différent d'un processus si ce n'est qu'il partage une mémoire commune avec son processus parent, ou un truc dans le genre.

Donc toi, tout ce que tu as à faire, c'est de faire générer par tes scripts paralléliser des fichiers (ou autre) dans lesquels ils consignent les informations que tu as besoin, et que ton script principal pourra aller consulter à tout moment.

[john.fender]

Ce n'est pas l'objet de ma recherche, merci de ne pas continuer à polluer ce thread avec une solution multiprocessus dont je ne veux pas et dont je connais parfaitement par ailleurs l'existence. Merci.

[I'm_HERE]

Ce n'est pas l'objet de ma recherche, merci de ne pas continuer à polluer ce thread avec une solution multiprocessus dont je ne veux pas et dont je connais parfaitement par ailleurs l'existence. Merci.

minnesota voulait seulement t'aider à trouver une solution à ton problème..

c'est dômmage pour ce forum....je venais juste de te péparer un petit script mutitâches mais, après avoir lu ton dernier post j'ai changer d'avis.

[john.fender]

Bonjour,

si tu veux discuter de ce genre de chose, fait le plutôt en MP s'il te plaît, ce n'est pas vraiment la place ici, la modération te le diras mieux que moi.

Par ailleurs, je te remercie pour le travail que tu as effectué, mais un script multitâche, ce n'est pas du multi-thread non plus (et c'est pourtant inscrit clairement dans le titre et dans les explications successives), à moins que tu utilises VBS (de dont je ne veux pas) ou un autre langage (ce qui n'est pas l'objet de ma demande) ou une commande (ce qui est l'objet de ma recherche).

Cdlt,

John.

[I'm_HERE]

salut,

si tu veux discuter de ce genre de chose, fait le plutôt en MP s'il te plaît, ce n'est pas vraiment la place ici,

t'as raison, le MP a été fait pour ce genre de chose..

mais un script multitâche, ce n'est pas du multi-thread non plus

non, multi-tâches c'est la traduction exacte du multi-thread

ou une commande (ce qui est l'objet de ma recherche).

non, c'est du pure scripting de commandes NT...essayes de comprendre ce script, il t'aidera à mieux comprendre le fonctionnement le de l'interpréteur de commandes..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
@echo off
If "%1"=="" (goto :s) Else Call :Fonction%1 >Con
exit /b

:Fonction1
for %%a in (A B C) Do (
   echo=%0 %%a
   for /l %%a in (1 1 9000) Do ver>nul
)
goto :EOF
:Fonction2
for %%a in (D E F) Do (
   echo=%0 %%a
   for /l %%a in (1 1 9000) Do ver>nul
)   
goto :EOF

:s
>con %0 1 | %0 2
goto :EOF

Bonne chance

[john.fender]

Bonjour,

Ton script utilise le mot clé con qui désigne la console elle même, ce qui te permet de la faire boucler sur elle même par le jeu des entrées sorties sur le fichier STDIN, sans jamais changer de PID. Pour autant, tu utilises la commande ver pour ta démo, qui est une commande interne au cmd. J'ai remplacé ver par un sleep dans ton script et j'ai utilisé Plist derrière, voici le résultat :



Es-ce que cela suffit pour te démontrer que cmd n'est pas multithread ?

Tu peux faire du multitâche de différente manière, mais un thread c'est toujours un sous-processus et non un 2° processus crée pour l'occasion.

Si tu veux tout savoir, je suis un train de faire un sequenceur en perl puisque je vois que tu le connais, mais je ne veux pas des dépendances de ce dernier : j'aime PERL uniquement en tant que remplaçant du batch, pas avec 10 000 librairies. Voilà pourquoi je recherche un start multithread, mais je crois que je vais finir par le coder en delphi.

ps : si tu as de la doc sur CON, je suis preneur, j'en trouve rarement à part le classique copy con...
pps : merci quand même, tu es un codeur toujours aussi doué, je dois l'admettre : )