[FDclone-users:00240] Re: ChangeLog for FDclone 2.04c

[Takashi SHIRAI <shirai@unixusers.net>]

　しらいです。

In Message-Id <20030929142423.B288953DCB@yuka.unixusers.net>
        Takashi SHIRAI <shirai@unixusers.net>writes:
> 　しらいです。

> 　対処法としては、select() を用いている term.c の compile 時
> のみ、-DFD_SETSIZE=256 として fd_set の bitmap size を必要な
> 分だけ用意するように指定しました。

　この Cygwin 用対策ですが、どうもこういう状況は他の OS でも
見られるようですね。
　FD_SETSIZE という識別子は POSIX で定められているので割と汎
用的なのですが、私が調べた限りでは Linux 以外の POSIX、即ち
SVR4 と 4.4BSD では全て FD_SETSIZE を pre define して compile
可能な実装になっていました。
　で、pre define しなかった場合の既定値と、process 辺りの最
大 open 数を比較してみたところ、FreeBSD 4.x など幾つかの環境
に於いて open 数の方が大きくなってしまっていました。

　特に FreeBSD 5.x に至っては最大 open 数が 3,000 を越える大
きな値となっており、ここまで来ると FD_SETSIZE として用意すべ
きサイズが膨大になるばかりか、select(2) 時に対象となる file
descriptor の数が多過ぎて不必要に時間がかかってしまいそうで
す。
　FDclone は shell でもあるので、端末用に open(2) した file
descriptor が小さな数値になってしまうと、redirect 用に用いる
仮 descriptor 値を食ってしまいます。
　例えば、普通に open(2) すると最初の file descriptor 値は 3
になりますが、これをこのまま用いると、FD#3 が空いていること
を前提に書かれた「3>&1」のような redirect がこの descriptor
を上書きしてしまいます。
　そこで、shell の実装では、こういった内部にしか見せたくない
file descriptor は最大値から順に取るように実装します。dup2(2)
を使って大きい値に振り替える訳ですね。
　こういう措置を施された端末用の file descriptor をそのまま
select(2) に渡してしまうと、実際には open されていないものも
含めて数千もの descriptor を調べることになってしまいます。

　そこで、この端末用 file descriptor の値がある程度以上大き
かった場合には、一旦 dup(2) して小さな値に振り替えた上で、そ
の descriptor を select(2) に渡すように実装しました。
　この閾値が小さ過ぎると、今度は dup(2)/close(2) の over head
の方が大きくなってしまうので、どの程度の値にするかは悩みどこ
ろではあるのですが、今は仮に 256 という値にしてあります。
　往年の UNIX では OPEN_MAX=64 でしたので、この値まではその
まま使った方が効率が良い筈です。閾値としては 64 より大きい値
なら何でも良さそうではありますが、kernel 能力の向上を考える
と 256 辺りが妥当な線かなと思っています。


　あと、話が逸れますが、Cygwin の端末 emulation には bug が
あるような気がしています。
　fork() 直後に子が open()/dup() 等の新規 descriptor 生成を
行なって、その最中に親が端末制御を行なった場合、一時的に端末
が入力を受け付けなくなってしまう様子です。
　この結果、一部の escape sequence が中途半端な状態で評価さ
れてしまい、画面表示属性がおかしくなってしまうことが割と頻繁
に起こります。
　タイミングの問題なので再現条件が難しいのですが、解析した結
果、可能なようなら FDclone 側で回避してみます。Cygwin 特有の
症状なので直せないかも知れません。

                                               しらい たかし