はじめてのにき

よく分かっていないのですが、
pipe用リングバッファが4kだったとして、PIPE_BUFも4096だったとして、さて、現在バッファが空であることをどうやって保証しましょうか？
なんて話になったりしませんか？

それは次読むポインタと次書くポインタが一致してればカラ、とかでダメですかね。

えーと、カーネルがもってるパイプのリングバッファのポインタはユーザランドからは分からないかと。
なにかプロトコル的なお約束がない限りはwriterはreaderが前回送った内容をすでに吸い取り済みかどうかは分からなかったりしません？

まさにそこが select のプロトコルという話なのでは。

selectでパイプが空になったら起床させるなんて出来ないような・・・

たしかに保証されてはいないですね

ユーザ空間で頑張るということではなく、 linux の select が実際どういう動きしてるのかな、というのが興味です。ちょっと実験した感じでは、 linux のパイプに関しては 4096B 以上出力できる時にだけ select がかえっているように見えます。

write(2) の pipe に対する atomic 保証の文面は、自然に考えると select が pipe に関しては 4096B 以上出力できる時にかえる、という動作も暗に示してると考えてもいいかなー的にも思ってしまいますが、まぁ「select については何も言ってない」というのが正しいですねそうですね…

ちゃんと新しいカーネルで調べたところ、pipeバッファが16ページに拡大されるときに、１ページまるっとあいてないと起きない実装に変わっているようです。
ほんますいませんm(_ _)m

実装の話としては、
パイプが 4K な Linux 2.4 で、
1byte でも中に入ってると select で writable にならないという挙動が見られました。

2.4.31のソースみたら、こんな素敵なコードが・・
つまり、emptyだったらwritebleで、そうじゃなかったらreadableという排他的な関係。

pipe_poll(struct file *filp, poll_table *wait)
{
(snip)
        mask = POLLIN | POLLRDNORM;
        if (PIPE_EMPTY(*inode))
                mask = POLLOUT | POLLWRNORM;