[ruby-list:26208] Re: fork problem?

In article <[e-mail]>,
  [e-mail] (Yukihiro Matsumoto) writes:

> 「seekしないと書き込みを保証しない」とman pageに書いてありま
> した。Rubyでは双方向ストリームも扱うのでそれは望ましくないで
> すよね。

えーと、fdopen の話ですよね。これはまぁ普通のファイルをバッファリング
して扱った時のことを考えれば理解できる仕様ではあります。

自動的に seek してくれるか、明示的に seek しないといけないかはともかく、
内部的に seek が発行されるのは仕方がないのでしょう。
(seek をせず、読み込み時にバッファリングをし、好き勝手な順番で読み書き
できる、というライブラリを作るのは不可能だと思う。)

> |そういう問題があることは不覚にも気がついていま
> |せんでしたが、ひとつの fd に対して 2回 fdopen するするわけにはいかない
> |んでしょうか? 
> |(片方でしか close できないから memory leak してしまうか?)
> 
> そう思って今はdupしているわけです。もうちょっと調査が必要で
> しょうか？ fclose(3)のエラーを無視すれば、問題ないのかなあ。

fd = fileno(f)
tmpflag = fcntl(fd, F_GETFD);
tmpfd = dup(fd)
fclose(f)
dup2(tmpfd, fd)
fcntl(fd, F_SETFD, tmpflag);
close(tmpfd)

とすれば比較的穏やかに close 抜きの fclose と等価なことができることに
気がつきました。

まぁ、結局 close するならエラーを無視するのが一番だと思います。気にな
るなら errno が EBADF であることを確認しておくこともできますし。

> |> IO#fcntlやIO#ioctlがfとf2の両方にfcntl(2), ioctl(2)を呼べば
> |> 済む問題だといいんですが、どうなんでしょう？
> |
> |それでも済みます。たぶん。
> 
> CVS最新ではそうしてみました。

確認してみました。fcntl で file descriptor の継承をちゃんと防ぐことが
できています。

まぁ、close-on-exec についてはこれでいいとしても、他のもので困りそうで
すが。とりあえず F_DUPFD はまずいですね。

やはり f2 はトラブルの元だと思います。fcntl のような低レベルな操作を使
うとすぐに厄介事が出てきます。

# fcntl といえば、O_NONBLOCK にして IO#read して EAGAIN になると途中ま
# で読んだぶんが蒸発してしまう、という話は報告しましたっけ?

> |> いっそ、fork_and_kill_other_threadsをforkの標準仕様にしちゃ
> |> いましょうか。
> |
> |賛成です。
> 
> CVS最新ではそうしてみました。

確認してみました。ちゃんと thread が消えています。
-- 
[田中 哲][たなか あきら][Tanaka Akira]
「くっだらないコト聞いちゃったねー$(C⊇ ごっめーん$(C⊇」
  (魔法使い養成専門 マジックスター学院 2, 南澤ミヅキ)