Note du modérateur: Il faut à tout pris lire le forum qui suit cet article pou appréhender l'intérêt de l'article. La partie benchmark est en faîte invalide pour 2 raisons qui y sont expliquées, et l'auteur en est conscient. Il referra les tests après correction de l'une de ses erreurs, mais le vrai problème, c'est que ce qui est appelé 'named/unnamed pipes' sous windows n'est pas l'équivalent de l'appellation similaire sous unix.
Aller plus loin
- L'article chez IBM (6 clics)
- La souce sur UserLocal (5 clics)
# Validité du test
Posté par Jerome Demeyer . Évalué à 9.
la polémique serait que l'implémentation des Named Pipes par Microsoft serait différente de l'implémentation sur un Unix en général, linux en particulier. En gros, les MS-namedpipes ressembleraient plus à des sockets qu'autre chose.
Certes, mais la fonctionnalité est la meme, non ? Si on veux faire passer un flux de données d'un soft à un autre, on utilise ce namedpipe, quelle qu'en soit la facon dont c'est implémenté. Alors pourquoi ce test serait invalide ?
Ce que je retient, c'est que même les mécanismes simples inventés il y a trente ans, Microsoft est incapable de les implémenter correctement...c'est quand meme terrible, ça !
[^] # Re: Validité du test
Posté par schyzomarijks . Évalué à 4.
Moi, je crois surtout que les pipes ne sont optimisés sous WinXX car elles sont peu utilisées en programmmation système sous cette OS, il existe d'autres moyens plus efficaces et beaucoup plus utilisés pour faire des communication inter-process. (Message Windows, COM, DCOM...)
Voilà, c'est mon avis et je le partage.
[^] # Re: Validité du test
Posté par Olivier Jeannet . Évalué à 2.
J'en doute un peu, car j'imagine que tous ces COM/DCOM et compagnie, qui sont de relativement haut niveau, s'appuient sur des trucs plus bas niveau, des appels systèmes et des pipes ou des sockets. Il faut bien qu'à la base il y ait un moyen de communiquer entre processus, et ce moyen c'est (dans le concept) un pipe ou une socket (assez proche selon l'implémentation). Apparemment sous Windows c'est moyennement réalisé (je n'ai pas encore lu l'article j'avoue, je me fie aux commentaires).
Qu'on me corrige si je me trompe bien sûr.
[^] # Re: Validité du test
Posté par Benjamin . Évalué à 1.
(par exemple, est-ce que, avec DCOM, je peux faire l'équivalent d'un "ls qqc | grep qcc | cut qqc > progqqc", sachant que je ne suis pas programmeurs ?)
# Les meilleures pipes...
Posté par Anonyme . Évalué à -7.
[^] # Re: Les meilleures pipes...
Posté par Anonyme . Évalué à -5.
[^] # Re: Les meilleures pipes...
Posté par Anonyme . Évalué à -3.
# Oh oui !
Posté par Anonyme . Évalué à -2.
[^] # Re: Oh oui !
Posté par Loic Jaquemet . Évalué à -1.
[^] # Re: Oh oui !
Posté par Anonyme . Évalué à -1.
[^] # Re: Oh oui !
Posté par cedric . Évalué à 2.
Franchement, ce film vaut le detour pour ressortir plein de bonne humeur, a mourir de rire, les dialogues comme le scenario ;-)
# Dans MS-dos, y'avait un morceaux de pipes:
Posté par Anonyme . Évalué à -1.
dir > l_dir.txt
[^] # Re: Dans MS-dos, y'avait un morceau de pipes:
Posté par Ramón Perez (site web personnel) . Évalué à 2.
dir | more
[^] # Re: Dans MS-dos, y'avait un morceau de pipes:
Posté par Sébastien Koechlin . Évalué à 5.
Surprise ! Les commandes sont lancées séquenciellement et entre chaque commande, un fichier temporaire est créé dans le répertoire courant. Opération qui échoue lorsqu'il est impossible d'écrire dedans.
Drôle d'implémentation !
[^] # Re: Dans MS-dos, y'avait un caractère pipe:
Posté par Jerome Demeyer . Évalué à 1.
Ils nous feront quand même toujours rire, et rien que pour ca, dès fois je pardonne à microsoft...
--
Une journée sans rire est une journée perdue
[^] # Re: Dans MS-dos, y'avait un morceau de pipes:
Posté par Benjamin . Évalué à 1.
Et moi qui croyais que DOS avait de l'avance sur Windoze...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.