Embedded GLIBC - Wikipedia
Embedded GLIBC (EGLIBC)はGNU Cライブラリ(glibc)の派生物であり、glibcとのソース・バイナリ互換性を保ちながらも組み込み機器への利用に最適化した標準Cライブラリである。EGLIBCの著作者はこれはglibcのフォークを意図してはいない、また派生物であるとしながらも、glibcのコア開発者に却下されたパッチの受け入れを表明している[2]。EGLIBCはGNU LGPLのもと配布されるフリーソフトウェアである。 2009年5月、Debianは、glibcの開発プロセスに対する懸念により、glibcからEGLIBCへの移行を発表した[3][注釈 1]。それに続き、Ubuntuが9.10リリースよりこのライブラリに移行した。Ark LinuxもまたEGLIBCを使用している[4]。なおDebian自身は、2011年にリリースされた、6.0 (コードネーム: sq
マルチスレッドなコード中での rand() は重い？ | okuの日記 | スラド
Linux + glibc のスレッドで新たな謎が。 linux-2.6.13 + x86_64-pc-linux-gnu-gcc-3.4.4 + glibc-2.3.5 (Linux Thread) の組み合わせでしか試していないのですが、マルチスレッドなコードのループ中で rand(3) を使うとすさまじくマシンが重たくなります。 数十個もスレッドを作るとキーボードに反応するのにすら十数秒かかるようになりました。 一方、どういうわけだか rand_r(3) だと大丈夫です。 仮説: ひょっとして、rand(3) の seed を libc 内で弄る際に mutex とか semaphore とかでロックしているのではあるまいか？ (疑似乱数の直列性を守るため？) 証明: 面倒なので該当箇所を rand_r(3) に書き換えてほっかむり。 (^^; # NPTL だと違ったりするのでしょ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
