fork以外の手段で子プロセスを生成できないこんな世の中じゃ

　数日前にfork以外の手段で子プロセスを生成するというのを書いたが、よく考えてみると、fork以外の手段では（ポータブルな）プロセスの生成はできなかった。（posix_spawnはまぁ、中でfork呼んでそうな雰囲気だし…。）しかし、forkとexecはなぜこのような仕様になっているのか、という疑問が解明されない事には、まっさらなプロセスを何で作れないんだーという疑問に対する答えは出ない、というところまでは話を詰められたように思う。
　そこで、forkとexecの仕様に対する疑問について調べてみると、まぁ他にも同じ事を考えた人がいっぱいいた。そりゃそうだよね、疑問もつよね。
　いくつかページを読んだ中で納得のいく答えは、forkとexecが分かれてて、exec後もfile descriptorが引き継がれるという仕様だと、シェルが実装しやすい、というものだった。（どこで見かけたのか残念ながら忘れてしまったが、検索し直すとシステムプログラム（第3週）とかにそのような感じの記述がある。）これは確かに説得力がある。
　つまり、forkとexecがなぜこうなっているか仕様になっているかというと、サーバとシェル（の特にパイプやリダイレクションの機能）が書きやすかったからで、それはUNIXが作られた当時であれば需要のほぼ全部を満たしたんだろうし、今でも一部のセキュリティとかを超気にするアプリ以外には充分な機能である。というか、fork & execは非常に強力なモデルであり超便利であると言える。そしてこの便利過ぎるforkとexecがあればわざわざまっさらなプロセスを生成するシステムコールは必要なかったんだよ、という事で納得することにした。
　しかし今となっては、まっさらなプロセス生成用のポータブルなシステムコールもあると便利だよなぁ、と思う。付け忘れを気にしないといけないO_CLOEXECオプションよりもそっちの方が安全だし。って、もう既に誰かが提案してそうだけど…。