トップ «前の日記(2008-10-07) 最新 次の日記(2008-10-09)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|

ToDo:


2008-10-08

_ select

なんか #lowhacks で書く時は select から帰ってきた書き込み用 fd に 書くとブロックされちゃうかも >< とかいう話があって、 PIPE_BUF までは大丈夫だと適当に思ってたのだけど なんか勘違い的な。

http://cvs.m17n.org/~akr/diary/d2005_01.html#a2005_01_27_1

akr先生はダメだとおっしゃられている。 先生の投稿であるところの

http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/26552

とか

http://cr.yp.to/docs/unixport.html

を見ると、 まぁ PIPE_BUF までくらいなら 最近のシステムなら大丈夫だったりするのかなぁ… とか思わんでもないけど、 移植性とか考えるとやめとけって感じのようだ。

このへんもおもしろいな。

http://linux.derkeiler.com/Newsgroups/comp.os.linux.development.apps/2007-06/msg00150.html

うーむ基本的なことがわかってないなぁ。 linux 限定ならどうなんだろうな

(01:21)

_ Haskell FFI

http://itpro.nikkeibp.co.jp/article/COLUMN/20081006/316216/

ユーザレベルスレッドでこれができるってのはうーん、 FFI 呼ぶ前にネイティブスレッド作るか signal でなんとかするか、かな?

次のページ読むに thread pool 的なのがあるのか。

(01:36)

本日のツッコミ(全10件) [ツッコミを入れる]
_ kosaki (2014-05-24 02:28)

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

_ shinh (2014-05-24 02:28)

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

_ kosaki (2014-05-24 02:28)

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

_ akr (2014-05-24 02:28)

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

_ kosaki (2014-05-24 02:28)

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

_ akr (2014-05-24 02:28)

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

_ shinh (2014-05-24 02:28)

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

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

_ kosaki (2014-05-24 02:28)

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

_ akr (2014-05-24 02:28)

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

_ kosaki (2014-05-24 02:28)

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;

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2008年
10月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
1.shinh(2014-05-24 02:28) 2.haru-s(2014-05-24 02:28) 3.kzk(2014-05-24 02:28)
search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h