最近Rubyの著名デベロッパのakrさんがAPIデザインケーススタディという書籍を出版された。隙を見ては読んでいるのだけどこれが激烈に面白い。
役にも立たない一般原則とかいっさいすっ飛ばし、実例実例、また実例である。そしてすべての例がOSの制限やら過去との互換性やらいろいろな都合でトレードオフを勘案しながら取りうる選択肢のなかでのベストを見つけていくという題材になっているので話がどれもこれもが超面白い

みんな買おう。


それはさておき、一点だけちょっと微妙な記述をみつけたのでメモっておく。

P128からはじまる Column async-signal-safe関数 だけど

また、実際のところ、子プロセスでasync-signal-safeでない関数を使用す

るのは、珍しいことではありませんでした。たとえば、ネットワークサー

バの作り方の一つとして、クライアントからの接続のたびにforkを行い、

子プロセスでクライアントと通信する形態があります。この場合、子プロ

セスはexecしないので、POSIX的にはasync-signal-safeな関数しか使えませ

ん。しかし、実際にはさまざまな関数がかなり好き勝手に使われます。

　そのようなプログラムをサポートするため、多くのUnixではシングルス

レッドプログラムからforkで子プロセスを作った場合、async-signal-safeで

ない関数も問題なく動作するようになっています。ただし、その動作は

POSIXに反しているため、将来的にも動作が保証されるかはわかりません。

と書いてある（強調は筆者）んだけど、Open Group（現代ではPOSIXと同義）のforkのページを見ると（強調は筆者）

A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. 

なので、async-signal-safeの制限があるのは規格上も multi thread なプログラムだけである。わたしが規格をなにか見落としていないかぎり。