YamaKen
yamak****@bp*****
2005年 10月 21日 (金) 12:22:18 JST
ヤマケンです。 現在のuimのpthread対応はbrokenなので、一旦revertしたいと思います。 以下の2つの問題に対処して完成させようという意欲のある人がいれば おまかせしますので、来週頭ぐらいまでに声かけてください。 At Sun, 25 Sep 2005 00:24:46 +0900, yamak****@bp***** wrote: > > At Sat, 24 Sep 2005 23:07:54 +0900, > tkng****@xem***** wrote: > > > > libuimの関数は全て短時間で返ることが期待されるので、Thread safeにさえ > > なれば、これ以上mutexの粒度を下げても大してメリットは無いと思っていま > > す。というわけで、mutexの粒度を下げる予定はありません。というか、これで > > うまくいったら、mutex回りはもういじりたくないです。 > > これ以上lock粒度を下げるつもりがないというのは安心しました。でも > 現状でも必要以上に細かすぎるので、もっと粗くAPI関数の入口と出口 > だけでlock/unlockを行うようにしましょう。 > > それと、pthreadの存在検出だけでは不十分、というのは、どういう場合に問題 > > が起こるのでしょう？pthreadが存在する場合はそれをリンクするようにすれば > > それで動作上は問題ない（シングルスレッドなアプリケーションでパフォーマン > > スが少し無駄に落ちるだけ）ように思えます。 > > 最悪の場合クラッシュします。 > > pthread-enabledなexecutable/libraryとそうでないものを使い分ける > 環境が存在します。そういった環境ではpthread-enabledかどうかでラ > イブラリ関数の実シンボル名やcrt(C runtime)、フレームの構造も違っ > たりするので、基本的にpthread-enabledなオブジェクトをそうでない > ものとリンクする事は避ける必要があります(libcからして2通りあった > りします)。 今uimのconfigure.acを見てみたんですが、pthreadの存在検出は AC_CHECK_HEADERS([pthread.h])だけでコンパイラのオプション等が適 切に処理されてませんね。これだとpthread-enabledなライブラリとし ても正しくコンパイルできません。acx_pthread.m4とか見ると本来どう しなければいけないか理解できると思います。 ------------------------------- ヤマケン yamak****@bp*****
