ToDo:
36.9 。実はこのへんが平熱説。 でも頭痛いからなぁ。
そんなことよりずっと寝てたから やりたかったこと忘れまくった。
まぁそんなことより久々に俺言語作りたい欲が。
(23:39)
http://www-online.kek.jp/Seminar/fpgaseminar.html
via http://d.hatena.ne.jp/natsutan/20080923/1222128240
(11:56)
備忘録
apt -d libflash0c2 apt -d gnash apt -d libflash-mozplugin
こやつらを消さないと Adobe のが動かない。
(22:53)
http://www.nicovideo.jp/watch/sm4572867
すごいなーと思いつつも、 手動でもこの程度なんだな…っていう残念さも。
結局高速弾じゃないとなかなかシンクロを感じられないんだよなぁ。 あと光らせるのはずるいけどいいな
(23:12)
体調悪い上にやるべきことがあって 二日間何も無かった気がする…
やるべきことの方は、 なんかこいうのこんなにできない子だっけ、 って感じで時間がかかった。 なんか丸一日溶けたんじゃないか。 うぐぐ。
(02:16)
http://secretgeek.net/checklist.html
via http://d.hatena.ne.jp/KZR/20080920
これはべんりだ。 なんせ w3m で見たら
A simple checklist for fixing regular problems 1. Enable javascript [Refresh List] :: built with wscg :: submit items:: home (secretGeek)
って教えてくれた!
(21:32)
http://d.hatena.ne.jp/nazodane/20080918/1221748642
ふと矛盾したライセンスをかかげると全く使えなくなるのかな… とか思ったけど、別にそんなことない気がした。 要は全部守ればたぶんいいんだよな単に。 ライセンス変更可能で特許取得禁止だと、 えーと特許取得禁止なライセンスに変更するなら別にOKみたいなそういう。 ホントかな。
で、
とかだと完璧な矛盾ライセンス。
まぁそういう問題からフリーな GBL で 10 おくえんください
http://shinh.skr.jp/m/?date=20060817#p06
(00:08)
そいや前ふと考えたのを スレッドうんぬんで思い出したんだけど、 jmp と call の直後だけコンテキストスイッチする可能性がある アーキテクチャとかどうなのかな。 あとコンテキストスイッチしないバージョンの jmp とかあると 色々ラクで良い。 あと jmp とか call 無しで10万命令とか走らせると SIGILL 。
(00:12)
ホントにすばらしいのかな
http://www.kt.rim.or.jp/%7ekbk/zakkicho/08/zakkicho0809b.html#D20080915-2
call $
じゃいかんのか。
(01:28)
http://morihyphen.hp.infoseek.co.jp/log2/200809.html#091530
あー説得されるなぁ。 このへんは考えるたびに違う結論になる気がするんだよな。 今はスレッド派。 woさんと想定してる例が全然違う感じがして、 結局適材適所的なんじゃないかと思ったりとか。 一度イベント派vsスレッド派の宗教闘争とかするべきだな。
とりあえず前教えてもらった正反対の主張をはっておく。
http://www.spa.is.uec.ac.jp/~kinuko/survey/body/events-are-bad.html
で、この話で僕がとりあえず最初に想定するのは webサーバ的なサーバで、 サーバの main thread が accept した fd を 別スレッド以下 slave とでも呼ぶに渡すとかそういう。 で、そいうモデルだと slave から main の方に 送るデータってほとんど無いあたりで、 違いが出てくるのかなぁ。 データが密接に絡めが絡むほど スレッドの方が不利になってくるのは真だと思うし。
で少なくともこいうモデル考えてる時は、 状態遷移表とかきちんとやらんでも うやむやにしきれちゃうケースが多いんじゃないかなぁ…と思う。
とりあえずこっち系モデルで ぱっと思いつくイベントうざい例として、
void handleRequestSimple(int fd) {
read(fd);
// hogehoge
write(fd);
}
とかいう関数をリクエストが来るたびに呼ぶとする。 スレッドの方は
threadLibrary.create(&handleRequest);
とかしてて(もちろん現実的には thread pool なんだろうけど)、イベントの方は
eventLibrary.register(&handleRequest);
とかしてる感じだとする。
hogehoge が簡単な処理なら良いんだけど、 例えば proxy みたいに他のサーバからデータ 取ってくるようなケースだとすると、 スレッドなら
void handleRequest(int fd) {
read(fd);
foo();
requestAnotherServer();
bar();
write(fd);
}
とかそのまま書きゃいいわけだけど、 イベントの方だと、
void handleRequestDone(int fd) {
bar();
write(fd);
}
void handleRequest(int fd) {
read(fd);
foo();
requestAnotherServerAsync(bind(handleRequestDone, fd));
}
とかになるのかな。 まずこの関数増やすとかうざいんだけど、 それはまぁ問題ないとして、 例えば bar がバグってた時に本当にうざいんだよな。 スタックトレースとか見ると、 スレッドの方は、
bar handleRequest thread_main
とかになるのかな。 で、イベントの方は、
bar handleRequestDone EventLibrary::loop ... main
とかになって、これだと何がイヤだって言うと 誰が handleRequestDone を呼んだのかわかんなくなってるっていう点。 手続き的な思考に慣れてる身としては、 気持ち的には handleRequestDone は handleRequest が 呼んでるつもりだったんだけど、 それがスタックトレースに無くて、 バグを追跡しにくい、っていうような。
何かしら callback というのは書く方もイマイチだと思うけど、 少なくとも第三者によるコードの可読性を損ねるというのは ほぼ間違いないんじゃないかと思う。
まぁでもこのへんは僕のわかる範囲でも偏った議論で、 デバッガがイベントモデルサポートみたいなのを入れてくれればいいんじゃね、 スレッドはほどほどのサポートあるんだから不公平な比較だ、 みたいな話と、 スレッドは無限に作るわけにはいかない、っていう話がある。
後者の方はつまり、 thread pool に thread が えーとさっきの論文紹介によると10万スレッドあるとして、 いやそんだけあったら大丈夫だろ…って感じがするけど、 その10万全てがその全てが requestAnotherServer に使われてしまうと、 requestAnotherServer を伴わないような、 簡単な処理 handleRequestSimple とかをする余裕が あるのにできなくなってしまって、 結局イベントモデル的なものを併用しなくちゃいけなくなる、 っていう話。 いやまぁ10万スレッドあるなら大丈夫な気もするが…
あとまぁどうでもいいけど重要な話として、 10万スレッドもあるとデバッグが別の意味でムズいという話が。 つまりどれが重要なスレッドなのかさっぱりわからなくて、 デバッガなどでスタックトレース見る時にどのスレッド見ればいいのー的な。 まぁこれもデバッガおよびランタイムが賢くなればなんとかなるか。
あとまぁレースコンディションとかあると 再現しにくいバグが出うるっていう wo さんの指摘は その通りだと思うし、
あーうーんやっぱ適材適所的な感じなのかなぁ。 スレッドベースの GUI ライブラリとかあるのかな。 キーボードを待つスレッドとマウスを待つスレッドと… みたいなの。
ふーむ
(09:51)
http://twitter.com/kinaba/statuses/922906127
これ微妙に面白いなぁ本質的ではなさそうだけど 例えとしてはなんかよくわかる。
しかし考えるとすぐによくわからんくなるので、 一度俺はスレッドの明日を守る守護神であるという設定で wo さんととっくみあいが起きる程度の論争とかすべきなんだと思う。
まーでも適材適所くさい気がするなぁ。 僕がよく見るような、 単一の機能を提供してるようなサーバとか、 裏でなんかしつつユーザになんか見せる、とか その程度の単順なサーバだと たいていスレッドの方が良さげに思う。
あと上に書いたような、ユーザのリクエスト処理してる間に 時間かかる処理しなきゃなんないような、 つまるところプロキシサーバみたいな物体も 割とスレッドな物体じゃないかなぁと思う。 あとユーザが長時間セッションをはって コマンドを順々に叩いてくるような物体も、 手続き的に書けるって意味でまぁ嬉しいかな。
で、複雑に内部状態を変更しつつも 長時間かかる IO があるようなものはどうすればいいのだろうね…
あとそうだ。小さいものは貧乏症的な意味で thread 使いたくない。 sevilwm の ipc 部分は thread で書いた方がラクだったと思うけど、 そういう理由で select でやってる。
(23:56)
そういえば書いてなかった。
du でやると 70MB もあるんだよな。
単順にファイルサイズ足してくと 3.4MB だそうで。 Text Compression 引くと 2.26MB 。 総投稿数は 17384
(02:30)
http://jp.youtube.com/watch?v=IjYZ7E7f5CM
via http://twitter.com/alohakun/statuses/920239733
これ星取るルートとしては最短なのかな。 もちょい短かった気もするんだけど。
(02:37)
http://mb101bold.cocolog-nifty.com/blog/2008/08/post_0539.html
via http://risky-safety.org/~zinnia/d/2008/08/#20080826-t0-h3-p0
そいやこれは店に入ってから飯にありつけるまでの最速を目指してるとか かと思ってた。
(02:40)
木曜早起きしたので chrome で弾幕はってみる。 結構動いたのでこれはこれはと思った。
で木曜から土曜まで会社の hackathon 的なものに。 だいぶ前から触ってみたかった部分に 触るいい機会になって非常によかった。
帰ってから土曜は寝てた。 夜中にちょっとだけシューティングの基本部分を。
日曜は libBulletML を JS で実装してた。 accel や horizontal を完成させる 根性が湧いてこないあたり、 当時には勝てないもんだなぁと思う。 ただ単順な単位時間あたりにコード書ける量みたいなのは 増えてる気がしてそれは少し嬉しかった。 ただ集中が続かないのでトータルとしては遅い。
本当は bulletSurf なり abagames.util.bulletml なりを 使うべきだったんだろうけど、 前者はソースコードが見当たらんくて、 後者は AS よりは C++ の方が似てるんじゃねえかコレとか思って挫折した。
あとまぁ BulletML => JS のコンバータを JS で書いて libBulletML for JS にしたいかなぁとか思ったのもあって自分でやった。
あとは Lua をなんとかして JS で動かすべきだよね。
(03:04)
ってホントかな的なことをよく思うのだけど。
http://morihyphen.hp.infoseek.co.jp/log2/200809.html#2008-09-14
イベントの検証漏れってのがえーと何指してるのかよくわからなかった。
(20:52)
| 前 | 2025年 1月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ nanasi [おだいじに]
_ shinh [ありがとうございますー]