疑似端末 (pty) 関連のバグ

cc pty_bug.c ; ./a.out (MacOSX の場合)
cc pty_bug.c -lutil ; ./a.out (NetBSD の場合)

MacOSX 10.2 では直っていない模様です。

その後回避方法を探していろいろ調べたところ、次のことが分かりました。

• 子プロセスが tty を close() してから exit() すれば、データは失われない。
• _exit() のカーネル内部の処理で、全てのファイルディスクリプタを close してはいるのだが、userland から close() が呼ばれたときと、 _exit() の内部処理で close するときで振る舞いが異なる。
• userland から close() が呼ばれたときは、tty へ write されたデータが書き出されるのを待つ。この待ちはカーネル内部で

  ttylclose() -> ttywflush() -> ttywait() -> ttysleep() -> tsleep()

  という呼び出し連鎖のもとで行われる。
• exit() 中に close 処理を行う場合は、 上記呼び出し連鎖は同様に実行されるが、 _exit() の最中であるため、 tsleep() 内部で待ちを行わずにすぐに戻ってしまう (thread_should_abort(current_thread()) が真を返すため)。 その後、tty のキューの解放が行われるためデータが失われる。

MacOSX はカーネル内部でスレッドへの対応を行っているので、 私にとっては、 _exit() ひとつとってももかなりややこしい道筋をたどらないと動作が追えないと感じました。 上記記述についても、あまり自信がありません。

というわけで、回避方法は何通りか考えられるのですが、 とりあえずカーネルに手を入れてみることにしました。 現時点での最新のカーネルを CVS で獲得し、 こういった変更を行い、 コンパイルして (MacOSX 10.2 で) 使ってみています。 bug_pty.c は期待どおりの動作をすることは確認しましたし、 Emacs 21.3.50 の M-x grep がうまく動かない件も直っていることを確認しました。 しかし、他に悪影響を及ぼす恐れが大いにあるので、 しばらく検証が必要かと思います。

Mac OS X 10.3 ではこのバグは修正されています。

私よりはるか昔にこのバグを Apple に report してた人がいました。 つまり直すのに1年半以上。
ちなみに NetBSD-current でもちょっと前に似たような問題が起こってました。 すぐに修正されましたが。