pipe

どこにも出てる、標準的な利用例

#include <stdlib.h>
#include <unistd.h>
...

int fildes[2];
const int BSIZE = 100;
char buf[BSIZE];
ssize_t nbytes;
int status;

status = pipe(fildes);
switch (fork()) {
case 0:  /* Child - reads from pipe */
    close(fildes[1]);                       /* Write end is unused */
    nbytes = read(fildes[0], buf, BSIZE);   /* Get data from pipe */
    /* At this point, a further read would see end-of-file ... */
    close(fildes[0]);                       /* Finished with pipe */
    exit(EXIT_SUCCESS);
default:  /* Parent - writes to pipe */
    close(fildes[0]);                       /* Read end is unused */
    write(fildes[1], "Hello world\n", 12);  /* Write data on pipe */
    close(fildes[1]);                       /* Child will see EOF */
    exit(EXIT_SUCCESS);
}

forkする前に、pipeを作成しておくのが味噌。親のパイプが子に継承される。 unixの大発明だと思うぞ。

前回lsofで調べた時、pipeは内部的に使用してなかったけど、ユーザーには公 開されてる。

(receive (in out) (sys-pipe)
  (display "abc\n" out)
  (flush out)
  (read-line in)) ⇒ "abc"

(sys-pipe)
#<iport (pipe) 0x7f43dbe54cc0>
#<oport (pipe) 0x7f43dbe54bb0>

わざわざポートをクローズしなくても、トイレの水を流す様に、フィラッシュ すればいいのか。この方法は、標準的な技だな。pipeでも通用する。そりゃ、 ファイルの一形態ですからね。

guileだと flush の代わりに force-output を使う。schemeって方言有杉。

scheme@(guile-user)> (define my (pipe))
scheme@(guile-user)> (display "hello" (cdr my))
scheme@(guile-user)> (force-output (cdr my))
scheme@(guile-user)> (read (car my))
$6 = hello

有名なので、当然有る。

図解 io.Pipe(Golang)

Go言語のio.Pipeでファイルを効率よくアップロードする方法

rubyにも有るはず。

ob$ ri pipe
  :
  rd, wr = IO.pipe

  if fork
    wr.close
    puts "Parent got: <#{rd.read}>"
    rd.close
    Process.wait
  else
    rd.close
    puts 'Sending message to parent'
    wr.write "Hi Dad"
    wr.close
  end

manの説明と同様なのが出てきた。カジュアルに使うには大袈裟すぎる。もっ と軽く使いたい。そんな要求には、

ob$ ri popen
 :
 IO.popen('ls -l') do |pipe|
    pipe.readlines
  end

こういうのが良い。昔、散々お世話になったな。懐かしい!!

#include <stdio.h>
#define MAXLINE 256

int main() {
  char buf[MAXLINE];
  FILE *fdr, *fdw;

  fdr = popen("ls", "r");
  fdw = popen("sort -r", "w");

  while(fgets(buf, MAXLINE, fdr) != NULL){
    fputs(buf, fdw);
  }

  pclose(fdr);
  pclose(fdw);
  return 0;
}

ls | sort -r 相当を実現してみた。もっと実用的なコードとしては、オイラー の大好きな奴との組み合わせ。 C言語からgnuplotを操作する なんてのがネットにあがっていました。

/usr/src/lib/libc/gen/popen.c にpopenとpcloseが定義されてた。下記は、 popenの骨格。

/*      $OpenBSD: popen.c,v 1.22 2019/06/28 13:32:41 deraadt Exp $ */

FILE *
popen(const char *program, const char *type)

        if (pipe2(pdes, O_CLOEXEC) == -1) {

        switch (pid = vfork()) {
        case 0:                         /* Child. */
                execl(_PATH_BSHELL, "sh", "-c", program, (char *)NULL);

       /* Parent; assume fdopen can't fail. */
        target = *type == 'w';
        iop = fdopen(pdes[target], type);
        fwide(iop, -1);

	return (iop);

ちゃっかり、pipe2が利用されてた。このソースの作成日は、丁度pipe2が出た あたりと思う。便利かどうか、試してみましたって感じだな。

昔、解析された方がおられた。大変なコードだったのね。 C言語系/「デーモン君のソース探検」読書メモ/A10, popen(3)

ちょいと気になるのは、popen.cのソースの在処。libc/gen/ がオイラー的に は謎だ。単なるラッパーだとは思うけど。サンプルをgdbしてみる。

(gdb) b pipe2
Function "pipe2" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (pipe2) pending.
(gdb) r
Starting program: /tmp/a.out

Breakpoint 1, pipe2 () at /tmp/-:2
2       /tmp/-: No such file or directory.
(gdb) bt
#0  pipe2 () at /tmp/-:2
#1  0x0b6e607c in _libc_popen (program=0x140ef3d4 "ls", type=0x140ef3d7 "r")
    at /usr/src/lib/libc/gen/popen.c:73
#2  0x140f07cb in main () at popen.c:8

うん、確かに、接頭語の _libc_ が付いて、ラッパーにはなってるけど、ど うして、こんな面倒な事をやってるの？

ob$ find /usr/src/lib -type d -name gen
/usr/src/lib/libc/arch/aarch64/gen
/usr/src/lib/libc/arch/alpha/gen
/usr/src/lib/libc/arch/amd64/gen
/usr/src/lib/libc/arch/arm/gen
/usr/src/lib/libc/arch/hppa/gen
/usr/src/lib/libc/arch/i386/gen
/usr/src/lib/libc/arch/m88k/gen
/usr/src/lib/libc/arch/mips64/gen
/usr/src/lib/libc/arch/powerpc/gen
/usr/src/lib/libc/arch/powerpc64/gen
/usr/src/lib/libc/arch/riscv64/gen
/usr/src/lib/libc/arch/sh/gen
/usr/src/lib/libc/arch/sparc64/gen
/usr/src/lib/libc/gen

libと言えどもマシンに依存する部分が有るんだな。それを考慮して自動変換 とかをやってるっぽいな。

MITに入学します。前の教材はxv6と言う悪貨でしたけど、それを若者に押しつ けるのは、忍びないって事で、希望に溢れたRISCVな石です。

ユーザーランドでは、shでpipeが利用されてました。カーネル側では、 sysfile.c に sys_pipe が実装されてました。

if(pipealloc(&rf, &wf) < 0)
if((fd0 = fdalloc(rf)) < 0 || (fd1 = fdalloc(wf)) < 0){
if(copyout(p->pagetable, fdarray, (char*)&fd0, sizeof(fd0)) < 0 ||
   copyout(p->pagetable, fdarray+sizeof(fd0), (char *)&fd1, sizeof(fd1)) < 0){

概略はこんな感じ。pipe.c内で定義されてる、pipeallocで4Kのエリアを持つ パイプ構造体をカー ネル内に確保。それをパイプ用のファイルと見做す様に設定。

次にfdallocで、現在のプロセスに結びつける。後は、その結果ををcopyoutを 使って、ユーザーランドに転送。fdarrayってのは、ユーザー側の受領先。何 で、2回に分けて転送してるのだろう？

// Copy from kernel to user.
// Copy len bytes from src to virtual address dstva in a given page table.
// Return 0 on success, -1 on error.
int
copyout(pagetable_t pagetable, uint64 dstva, char *src, uint64 len)
{
  uint64 n, va0, pa0;

  while(len > 0){
    va0 = PGROUNDDOWN(dstva);
    pa0 = walkaddr(pagetable, va0);
    if(pa0 == 0)
      return -1;
    n = PGSIZE - (dstva - va0);
    if(n > len)
      n = len;
    memmove((void *)(pa0 + (dstva - va0)), src, n);

    len -= n;
    src += n;
    dstva = va0 + PGSIZE;
  }
  return 0;
}

これを見る限り、1回の転送でも(この場合は)大丈夫と思うんだけど。 凡クラー ズには、想像も出来ないような、深淵な理由があるのだろうか？ じゃ、ちょっ と河岸を変えてみるか。

今更感は有りますが、ソースがDISKの肥やしにしとくのでは、勿体ないので、 脳の肥やしとして、活用します。ついでに、古い本、"MINIXオペレーティグシ ステム"なんてのも活用します。

fs/pipe.c

* The entry points into this file are
*   do_pipe:     perform the PIPE system call
*   pipe_check:  check to see that a read or write on a pipe is feasible now
*   suspend:     suspend a process that cannot do a requested read or write
*   release:     check to see if a suspended process can be released and do
*   revive:      mark a suspended process as able to run again
*   do_unpause:  a signal has been sent to a process; see if it suspended  

do_pipe から追跡を始めたんだけど、こりゃ本を読むのが先だな。密接に ファイルシステムと結合してるわい。 それにminixと言う特殊性も有るみたいだし。。。

次回に続く(かも知れない)。