Journal Pipes nommés sous Windows

Posté par  .
Étiquettes : aucune
0
31
juil.
2003
Bonjour mon journal,

J'ai une appli en tcl/tk qui tourne sous linux et solaris, qui comporte plusieurs fenètres qui communiquent par des pipes.
Et là je voudrais (enfin mon chef voudrait...) que ca tourne aussi sous windows.
Mon problème est donc que j'ai pas trouvé comment faire créer les pipes nommés sous windows (nt4 ou 2000).
J'ai essayé avec cygwin, mais mknod a l'air de pas être implémenté.
J'ai essayé aussi avec fileutils de gnuwin32 mais rien à faire un mknod test p ne veut rien faire.

Est-ce que quelqu'un connaitrait un moyen de faire ca simplement, avec un code portable windows/unix ?

Merci d'avance mon journal
  • # Re: Pipes nommés sous Windows

    Posté par  . Évalué à 1.

    j'avais cherché pour utiliser gnuplot comme traceur dans un prog win32, et j'ai jamais trouvé. Il existe un pipe pas nommé dans l'API win32 je crois, mais niveau portabilité...
    Ptetre que cygwin gere les socket unix, on peut rever :)
    • [^] # Re: Pipes nommés sous Windows

      Posté par  (site web personnel) . Évalué à 1.

      qqn peut me rapeller c'est quoi la difference entre une socket AF_INET et une AF_UNIX? j'ai oublié :) je sais, je pourrais rechercher avec un zoli moteur de recherche - qui sont nos amis comme chacun sait - mais y a surement plein de gens compétents ici qui voudrons bien partager leur savoir.
      • [^] # Re: Pipes nommés sous Windows

        Posté par  (site web personnel) . Évalué à 2.

        Bon, j'suis impatient, j'ai finalement cherché sur un moteur :

        The two most common addressing schemes are AF_UNIX and AF_INET. AF_UNIX addressing uses UNIX pathnames to identify sockets; these sockets are very useful for IPC between processes on the same machine. AF_INET addressing uses Internet addresses which are four-byte numbers usually written as four decimal numbers separated by periods (such as 192.9.200.10). In addition to the machine address, there is also a port number which allows more than one AF_INET socket on each machine.

        Ca se traduirait par :

        Les deux systèmes d'adressage les plus communs sont AF_UNIX et AF_INET. L'adressage AF_UNIX utilise des chemins d'accés UNIX pour identifier les sockets; ces sockets sont trés utiles pour les communications inter-process sur la même machine. L'adressage AF_INET utilise des adresses Internet qui sont des nombres sur 4 octets habituellement représentés par 4 nombres décimaux séparés par des points (par exemple : 192.9.200.10). Bon, aprés, ca parle du port pour accéder à la socket, tout le monde aura compris :)

        Ca vient de là : http://world.std.com/~jimf/papers/sockets/sockets.html(...)


        En fait, y a pas grande différence entre une socket AF_UNIX et un pipe nomé!
  • # Re: Pipes nommés sous Windows

    Posté par  . Évalué à 1.

    Portabilité ? la tu rêves ! mais pour m'être frotté au problème, j'ai découvert ça:

    Il faut se rabattre sur les mailslots. Je suis un gros feignant et je te laisse cherche la doc :). L'interface utilise l'API du file system sous windows.
    Attention, c'est de plus en plus lent à chaque version de windows.

    Il y a aussi les Unix sockets qui sont disponibles aussi mais je ne sais pas ce que ca vaut et la portabilité (ou plutot la quantité de bugs) entre les différentes versions de windows.
    Attention aussi, les sockets sont à la sauce MS et il vaut mieux passer par une surcouche pour masquer la tuyauterie suplémentaire dans les sockets Windows.
    • [^] # Re: Pipes nommés sous Windows

      Posté par  . Évalué à 2.

      Oups ! Pardon, l'interface unix est disponible avewc windows.
      Donc le plus portable c'est les sockets unix (AF_UNIX, AF_INET c'est pour le IP [Internet Protocol]). Tu peux aussi passer par l'interface de boucle local si tu utilises AF_INET.
      Je n'ai aucune idée des performances mais ca doit pas être grandiose.
      • [^] # Re: Pipes nommés sous Windows

        Posté par  . Évalué à 2.

        Une socket Unix (AF_UNIX) ça ressemble vraiment bcp à un pipe nommé.
        La diff c'est que c'est en RW pour tout le monde alors que les pipes nommées ont un prog qui lit et un prog qui écrit.
        C'est bcp plus rapide qu'un socket AF_INET (en tout cas sur Linux).
  • # Comparatifs IBM

    Posté par  . Évalué à 3.

    Il y a les comparatifs de IBM developerWorks entre la version Linux et la version Windows (en terme d'API et de perf):

    pipes anonymes, mais apparemment sous win l'API est la meme pour les pipes nommés: http://www-106.ibm.com/developerworks/linux/library/l-rt4(...)

    synchro de process/thread, et encore des pipes : http://www-106.ibm.com/developerworks/linux/library/l-rt5(...)

    programmation socket: http://www-106.ibm.com/developerworks/linux/library/l-rt6(...)

    process et threads : http://www-106.ibm.com/developerworks/linux/library/l-rt7(...) , http://www-106.ibm.com/developerworks/linux/library/l-rt8(...)

    context-switching : http://www-106.ibm.com/developerworks/linux/library/l-rt9(...) et http://www-106.ibm.com/developerworks/linux/library/l-rt10(...)
  • # Re: Pipes nommés sous Windows

    Posté par  . Évalué à 1.

    Pourquoi pas utiliser des sockets ?
  • # Re: Pipes nommés sous Windows

    Posté par  (site web personnel) . Évalué à 2.

    J'ai eu un problème équivalent, j'avais réglé ça comme ça :
        global subproc
        switch $tcl_platform(platform) {
             windows {
                set subproc(input) [open "| $path" r+]
                set subproc(output) $subproc(input) 
                gets $subproc(output) ligne
                gets $subproc(output) ligne
                gets $subproc(output) ligne
                gets $subproc(output) ligne
                fconfigure $subproc(output) -blocking 0
            }   
            default {
                pipe pin_r pin_w
                pipe pout_r pout_w
                set f [fork]
                if {$f == 0} {
                    close stdin
                    dup $pin_r stdin
                    close $pin_w
                    close stdout
                    dup $pout_w stdout
                    close $pout_r
                    execl $path
                    exit
                }   
                set subproc(input) $pin_w
                    close $pin_r
                set subproc(output) $pout_r
                close $pout_w
                set l [gets $subproc(output)]
                fconfigure $pout_r -blocking 0
            }
        }
    
    Il y a surement mieux mais ca peut te donner des idees PS: le code tournait sans problème sur Linux, W98 et W2000 avec Tcl/TK d'Active).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.