Quelle est la meilleure solution pour emuler une série de pipes Unix sous Windows ?
2 réponses
pioche encore
Bonjour,
Mon probl=E8me est le suivant :
J'=E9tudie actuellement un produit de traitement de gros flux de
donn=E9es qui pos=E8de une impl=E9mentation pour Unix et Windows.
La version Unix est principalement d=E9velopp=E9e en Perl et fait
transiter le dit flux par diff=E9rents filtres au moyen de pipes
syst=E8me (rien que du traditionnel quoi).
La version windows est d=E9velopp=E9e en BZZZZ (peu importe mais c'est
bas=E9 sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires trait=E9s par des appels syst=E8mes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture s=E9quentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un r=E9pertoire par phase de traitement).
Or si je veux adapter le processus Unix =E0 la version Windows il me
faut r=E9soudre le probl=E8me de la gestion des pipes qui me semble t'il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
int=E9gralement avant de produire sur stdout).
D'ou ma question : est il coh=E9rent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Dominique Vaufreydaz
Bonjour,
Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t'il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP. C'est toi qui gere ce que tu lis et comment. Et en local, c'est presque de la memoire partagée (c'est plutot un stream partagé). En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Une idée comme ca. Doms.
Bonjour,
Mon problème est le suivant :
J'étudie actuellement un produit de traitement de gros flux de
données qui posède une implémentation pour Unix et Windows.
La version Unix est principalement développée en Perl et fait
transiter le dit flux par différents filtres au moyen de pipes
système (rien que du traditionnel quoi).
La version windows est développée en BZZZZ (peu importe mais c'est
basé sur l'API WIN32) et fait transiter le flux par des fichiers
temporaires traités par des appels systèmes aux filtres (des .exe).
Le pb est que l'ouverture et la fermeture séquentielle des fichiers
rend la vesion Windows est plus lente et plus gourmande en espace
de stockage (un répertoire par phase de traitement).
Or si je veux adapter le processus Unix à la version Windows il me
faut résoudre le problème de la gestion des pipes qui me semble t'il
n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch
(du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
sous Windows comme on le ferait dans un shell Unix ?
Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP.
C'est toi qui gere ce que tu lis et comment. Et en local, c'est
presque de la memoire partagée (c'est plutot un stream partagé).
En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Mon problème est le suivant : J'étudie actuellement un produit de traitement de gros flux de données qui posède une implémentation pour Unix et Windows. La version Unix est principalement développée en Perl et fait transiter le dit flux par différents filtres au moyen de pipes système (rien que du traditionnel quoi). La version windows est développée en BZZZZ (peu importe mais c'est basé sur l'API WIN32) et fait transiter le flux par des fichiers temporaires traités par des appels systèmes aux filtres (des .exe). Le pb est que l'ouverture et la fermeture séquentielle des fichiers rend la vesion Windows est plus lente et plus gourmande en espace de stockage (un répertoire par phase de traitement). Or si je veux adapter le processus Unix à la version Windows il me faut résoudre le problème de la gestion des pipes qui me semble t'il n'est pas asynchrone en mode 'commande' (le fichier stdin est lu intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
D'ou ma question : est il cohérent d'utiliser les pipes sous un batch (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) sous Windows comme on le ferait dans un shell Unix ? Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP. C'est toi qui gere ce que tu lis et comment. Et en local, c'est presque de la memoire partagée (c'est plutot un stream partagé). En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Une idée comme ca. Doms.
pioche encore
Tiens c'est marrant j'avais pourtant fait un suivi sur fr.cl.perl ...
Dominique Vaufreydaz a écrit :
Bonjour,
[...]
> Or si je veux adapter le processus Unix à la version Windows il me > faut résoudre le problème de la gestion des pipes qui me semble t' il > n'est pas asynchrone en mode 'commande' (le fichier stdin est lu > intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
En fait c'est improbable (au sens propre du terme). Sous cmd il est difficile de faire tourner 2 processus en simultané (les sorties de l'un alimentant les entrées de l'autre). En tout cas avec un batch ou un script contenant une boucle infinie, le second processus de la queue est définitivement pendu.
> D'ou ma question : est il cohérent d'utiliser les pipes sous un batch > (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) > sous Windows comme on le ferait dans un shell Unix ? > Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP. C'est toi qui gere ce que tu lis et comment. Et en local, c'est presque de la memoire partagée (c'est plutot un stream partagé). En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Une idée comme ca. Doms.
Oui ça remet pas mal de choses en cause dans l'existant mais il n'y a peut être pas d'autres solutions. Je vais voir dans la doc de perl pour Windows ce genre de problématique doit y être évoquée.
Tiens c'est marrant j'avais pourtant fait un suivi sur fr.cl.perl ...
Dominique Vaufreydaz a écrit :
Bonjour,
[...]
> Or si je veux adapter le processus Unix à la version Windows il me
> faut résoudre le problème de la gestion des pipes qui me semble t' il
> n'est pas asynchrone en mode 'commande' (le fichier stdin est lu
> intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
En fait c'est improbable (au sens propre du terme). Sous cmd il est
difficile de faire tourner 2 processus en simultané (les sorties de
l'un alimentant les entrées de l'autre). En tout cas avec un batch ou
un script contenant une boucle infinie, le second processus de la queue
est définitivement pendu.
> D'ou ma question : est il cohérent d'utiliser les pipes sous un batch
> (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus)
> sous Windows comme on le ferait dans un shell Unix ?
> Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP.
C'est toi qui gere ce que tu lis et comment. Et en local, c'est
presque de la memoire partagée (c'est plutot un stream partagé).
En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Une idée comme ca. Doms.
Oui ça remet pas mal de choses en cause dans l'existant mais il n'y a
peut être pas d'autres solutions. Je vais voir dans la doc de perl
pour Windows ce genre de problématique doit y être évoquée.
Tiens c'est marrant j'avais pourtant fait un suivi sur fr.cl.perl ...
Dominique Vaufreydaz a écrit :
Bonjour,
[...]
> Or si je veux adapter le processus Unix à la version Windows il me > faut résoudre le problème de la gestion des pipes qui me semble t' il > n'est pas asynchrone en mode 'commande' (le fichier stdin est lu > intégralement avant de produire sur stdout).
Tiens, je n'avais jamais remarqué ca...
En fait c'est improbable (au sens propre du terme). Sous cmd il est difficile de faire tourner 2 processus en simultané (les sorties de l'un alimentant les entrées de l'autre). En tout cas avec un batch ou un script contenant une boucle infinie, le second processus de la queue est définitivement pendu.
> D'ou ma question : est il cohérent d'utiliser les pipes sous un batch > (du type cmd.exe/dos-oui-je-sais-ca-n-existe-plus) > sous Windows comme on le ferait dans un shell Unix ? > Y'a t'il une alternative aux pipes avec Perl sous Windows ?
L'alternative a ce genre de chose est l'utilisation de TCP/IP. C'est toi qui gere ce que tu lis et comment. Et en local, c'est presque de la memoire partagée (c'est plutot un stream partagé). En plusn la version en perl fonctionnera aussi sous Linux/MacOS.
Une idée comme ca. Doms.
Oui ça remet pas mal de choses en cause dans l'existant mais il n'y a peut être pas d'autres solutions. Je vais voir dans la doc de perl pour Windows ce genre de problématique doit y être évoquée.
