>> しばらく考えたところ、書き込み側で atomic ops 使えば十分という気がしてきました。
>> それなら、readerは速度低下０なのでパフォーマンス問題がおこりようがないし。
>> Linuxでしかテストしてませんが、こんなもんでどうでしょうか？
>
> 　atomic operation が十分に仮定できるのなら，これでもいいような気がします．
>
> 　ちなみに，rb_atomic_t は int でいいのかしら，とちょっと思った（いや，
> この辺の常識を知らないもので．rb_atomic_int_t じゃないんだな，って）．

Windows は LONG しかサポートしてないですし、厳密な話をするとsparcとかは
命令セットの都合上たしかintの中でも24bitぐらいしか使えないはずなので、
型名にintを入れるのは反対です。

あと、64bitなatomic ops は出来ない32bit CPUが多いので、32bit CPUが滅ぶまで
あんまり検討にいれたくないとか思ってます。ごにょごにょ


> 　自分が持っている対案は，interrupt_flag はあくまでヒントとして扱い，何
> か不都合があっても後でリカバーできる情報にしておく．消しちゃ行けない情報
> （シグナルの到達判定とか）は，別に用意して，それを参照しなくてはいけない
> シチュエーション（GVL の外でシグナル監視とか）は，そっちも参照する，とい
> うのがいいんでないかと思っていましたが，複雑です．小崎さんの提案は，その
> 点で interrupt_flag をキッチリかっちり管理する，という意味でわかりやすい
> と思います

Windowsとgcc 以外については、いままでと同じ動作になるので「今より悪くなることはない」
という意味で許容範囲かなと思ってました。

また、atomic opsがポータビリティーを下げる可能性についても考えましたが、現状すでに
signal 処理が atomic ops に依存している以上、悪化しようがないと思います。たんに既知の
問題（非Windowsかつ非gcc環境でたまにレースコンディションで悲しい思いをする）が直らないだけです。で、ユースケースを考えてみてもそういうプラットフォームで365日
RoRをぶん回すとかきっとしてないと思うので、実用上問題ないでしょう。better awk として使う限り、そうそう当たりませんですし。

別案として、３つのビットフラグを別の変数にしてしまうというのがあったのですが、ささださんから
IRCで RUBY_VM_CHECK_INTS() でロード命令が２つ増えるのが気になると指摘されたため
変更した経緯があります。（が、正直いうとロード命令２つって誤差だと思うんですよ）

最後にささださんの提案に対する見解ですが、大幅なメリットが見つかるまでは反対です。
そういうトリッキーな実装は「セキュリティイシューが上がってきたから至急かつ、ABIを壊さない形で直さないといけないけど良い案がないー」とかいう状況でしかたなくやるものであって、普段からやるのはいかがなものかと思います。ささださんが理解していても、別の誰かがそのうち前提を壊すコミットする可能性が高いという意味で

・・・と、いろいろと説得材料をならべてみましたが、どうしても反対というのであれば私は手を引きます。