ファイル I/O でブロックされているスレッドを殺したくなったらどうするか？ - NyaRuRuが地球にいたころ
やっていてふと思ったのですが、タイムアウト付きのExistsメソッドを使っても、タイムアウトするまでアプリケーションがフリーズしてしまいます。 Exists自体を別スレッドに任せた方がよいのでしょうか？ 普通はどのように設計するものなのでしょう。 スタンダードな手法等があれば、御教授よろしくおねがいします。 答え 例えば，Windows XP や Windows Server 2003，およびそれ以前の Windows を避ける 実は奥が深い I/O Cancel 実はこれは結構奥が深い問題です．ただまあ上で質問されている方はそこまで深い話が必要というわけでもないような気もしますが．というわけで以下は一般教養としてどうぞ． 致命的でないケース 従来の Windows では，OS API レベルでの I/O Cancel モデルが不十分だったため，その上に位置する .NET や各種 CUI
ソートと統計 - NyaRuRuが地球にいたころ
ソートの話をするときは，はじめに軽くネタを振ってオーディエンスの偏り具合とかバラつき具合を調べておいて，最良の話題を選びましょう Rの発言: 「ソートする時にさ、はじめにいっぺんデータを頭からなめて偏り具合とかバラつき具合を調べておいて、最良のソートアルゴリズムを選んで...」 これに周りのやつらが噛みつく: 「そんなもん、データ読み込むたんびにソートしとけば全部読み終わったときゃソート終わってんぢゃん」 R少なからず凹んだ様子。 まあデータを一回スキャンしたところで所詮 N Log(N) が N (Log(N)+1) になる程度の話なので (つまりマクロには無視できる)，N が大きくなってくると普通に有効な戦略だと思います．別に全部調べなくてもサンプリングしても良いですし，並列化して事前スキャンという手もあるでしょう． とはいえ，そういう話もオーディエンスは選んだ方が良いんでしょうな．N
Windows で Large Page は「使える」か？ - NyaRuRuが地球にいたころ
VirtualAlloc で実験していたネタもついでに放出． Firefox 版 jemalloc のソースを読んでいて，デフォルト chunk size が 1 MB と比較的大きかったので，「それなら Large Page 割り当てても良いんじゃなかろうか？」と調べてみました．もっとも，結論から言えば，Windows 環境の Firefox のメモリアロケータに Large Page を使うのは，全く現実的ではないということが分かっただけでしたが． Large page support Windows Server 2003 から，ユーザーモードアプリケーションでも large page が使用できるようになった．Windows Vista でもサポートされる．VirtualAlloc に MEM_LARGE_PAGES フラグを付ける．large page の最小サイズは GetLa
Windows のヒープ管理 - Firefox3 のメモリ使用量 (2) - NyaRuRuが地球にいたころ
シアトル行く前に『jemalloc on Windows - Firefox3 のメモリ使用量 - NyaRuRuの日記』 の続きを片付けておきますか． といいつつ，当初予定の内容はとりあえず破棄．書いているうちに気になることが色々出てきて，その度に実験するものだからあんまり進んでいなくて，このままだと永遠に終わらなそうなので方針を変えました．というわけで外部資料多めでお送りします． 最初に読むもの UNIX 系の mmap を使ったメモリアロケーションならだいたい分かるよ，という人が，Windows のメモリ管理について興味を持ったとして，おすすめなのが 「（新）APIから知るWindowsの仕組み」シリーズの『第4回 メモリー管理のキー技術「仮想メモリー」を知る』という記事です． というわけでここでまず上のページに飛んで，一通り読んでみて下さい．以下はその後で． 仮想アドレス領域の予約
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
