[FDclone-users:00163] Re: {FreeBSD,OpenBSD}/sparc64, IA64(AIX対応その後)

[SHIOTA Shoichi <Shoichi.Shiota@lightwell.co.jp>]

潮田です。

Takashi SHIRAI <shirai@unixusers.net> wrote:

> 　この本は UNIX の bible なので私も新旧両方持っているのです
> が、会社に置いてあるために最近忙しくて読めていませんでした。
> 今朝読んで私もこれが原因かと思いました。
バイブルですか。
購入してみます。

> 　なので、POSIX 的には「signal() は使用禁止」と読むべきかも
> 知れませんね。
POSIX の規格書（？）等は持っていないので、 
「The Single UNIX? Specification, Version 2」の Web 版を
ローカルに落としてきて見ているのですが、
> new applications should use sigaction() rather than signal().
程度なんですよね。
signal() も wait3() みたいに　LEGACY  とか書いてほしいですね。
（ただの愚痴です）

> 　FDclone の policy では、例えある環境では不要の code であっ
> ても、別の環境では必須の code であるようなら、無駄を承知の上
> で実装しておく方が安全だという判断に基づいています。
これは、正しい方針だし、そうあるべきだと思います。


> 　2.03a に対する patch を考えてみました。素の 2.03a と、この
> patch 適用後の比較をしたいので、AIX 環境で以下の検証をしてみ
> て頂けないでしょうか？
> 	1. ./fd で PAGER や EDITOR 等の子 process を起動する。
子供の終了後、しばらくたって
Segmentation fault
で shell へおちる。

> 	2. ./fdsh で sleep や /bin/echo 等の子 process を起
> 	   動する。
子供の終了後、しばらくたって
Illegal instruction
で 元の shell へおちる。

> 	3. ./fdsh で「&」付の back ground job として 2. と同
> 	   様の検証。
sleep は 2. と同様。

echo は、そのままバックで停止したままになる。
(これは、他の shell でもそうなるので、それで正しいのですよね)
fg で表に持ってくれば、2. と同様になる。

> 	4. ./fd で set -b を実行した後 1. と同様の検証。
子供の終了時に、正常に FD へ戻ってくる。

> 	5. ./fdsh で set -b を実行した後 2., 3. と同様の検証。
2. は、子供の終了後
./fdsh: No child processes
と表示し、 fdsh へ戻るようになる。

3. の sleep は正しく終了する。
echo はバックで停止する。
fg 後は正常終了する。

> 	6. ./fdbsh で 2., 3. と同様の検証。
2. は 2. と同様。
3. は Illegal instruction で、元の shell へ。
(echo も停止することなく動作)


> 	8. 作りなおした ./fd, ./fdsh, ./fdbsh に対して 1.-6.
> 	   を再度検証。
> 
* 1. 
ただしく FD へもどってくる。

* 2.
子供の終了後
./fdsh: No child processes
と表示し、 fdsh へ戻るようになる。

* 3.
sleep は正常終了。
echo は、そのままバックで停止したままになる。
fg 後は正常終了。

* 4.
ただしく FD へ戻ってくる。

* 5.
2. の方は
子供の終了後
./fdsh: No child processes
と表示し、 fdsh へ戻るようになる。

3. の方は
sleep は正常終了。
echo は、バックで停止。
fg 後は正常終了。

* 6.
2. の方は
子供の終了後
./fdbsh: No child processes
と表示し、 fdbsh へ戻るようになる。

3. の方は正常終了。
echo もバックで止まらない。

> 　これが 7. の patch 適用により全てのケースで解消されるよう
> であれば、この実装で暫く様子を見てみて下さい。
patch で問題は解消されているですが、
./fdsh: No child processes
の表示が気になります。
ハンドラーの内部で waitpid() しているので、もともと存在する
wait() が余分になっているぐらいでしょうか。
（また甘いかな）


> 　そういう意味では HP-UX についても全く同じことが言える筈で
> すが、HP-UX の signal() は SA_RESETHAND だけでなく SA_NOCLDSTOP
> も有効にしているので、この合わせ技により signal() を使っても
> 無限 SIGCHLD 発呼が回避出来ているのかも知れません。
> 　[FDclone-users:00155] の実験で、sa_flags = SA_RESETHAND |
> SA_NOCLDSTOP にしてみると無限発呼が解消されたりはしませんか？
> AIX ではこの併用の効果は無かったようですけど。
再度確認のため AIX 5.1.0 で
sa_flags = 0;
sa_flags = SA_RESETHAND;
sa_flags = SA_RESETHAND | SA_NOCLDSTOP;
sa_flags = SA_RESETHAND | SA_NOCLDSTOP | SA_NODEFER;
の４通りを試しましたが、 0 以外は暴走でした。


> ＃　後は SVR3 上で 0-8. の検証が出来れば良いのですが、どこか
> ＃に古い機械が転がってませんかね？
> ＃　HP-UX だと 7.0 辺りから段階的に SVR3 -> SVR4 に移行して
> ＃いるようで、signal() の旧実装が 7.0-10.0 のどこで消えたの
> ＃か判りません。
> ＃　AIX だと 3.x 以降が SVR4 らしいです。A/UX だと 2.x 以降。
> ＃意外と IRIX 辺りが未だに SVR3 のままの実装を引きずっている
> ＃かも知れません。
もう一台 HP の WS があるのですが、それでも既に 10.0 に
なっていました。
AIX も最初に触ったときに既に 3.2.4 でしたし。
古いマシンを抱えているとなると大学ですかね。