- 29 名前：22 mailto:sage [2013/06/15(土) 22:08:34.16 ]
- >>25
> auto-complete-clang-async.el ネタです。
> 前スレでこの話があったけど、 >22 の人かな？
はいそうです。
> 純粋にたくさんファイルを開いたときならダメだけど、そうではなくて clang-complete プロセスが
> いっぱい残る問題ならこれでたぶん解消すると思います。
auto-complete-clang-asyncの問題としては、
・バッファ毎にclang-complete.exeを割り当てるので
ファイルを８個以上ひらくとパイプエラーになってしまうのでそれ以上開けない。
・64bit版がない。
というのがあるので
64bit版のclang-complete.exe相当のものを自作して試しています。
1バッファ１プロセス起動はやめて、ｎバッファ１プロセスという形にしています。
なのでclangの補完対象になるバッファは全て１つのclang-complete.exeで管理しています。
ここで問題がおきていて、
あるバッファでclang-compelteへ補完コマンドを送信中に
裏でCEDETが動作して、別バッファにincludeされる対象のファイルを自動的にオープンすることがあり
その際にc-common-hookなどにセットしてあるclang-completeへの登録コマンドなどが動作して
clang-completeのstdinに入ります。
これで応答がなくなってしまったことがあり
このときに、コマンドの送信順番がどうなるかが気になっています。
process-connection-typeがnilの場合でも
process-send-string単位ということなので
バッファAのprocess-send-stringと
バッファBのprocess-send-stringが
入り乱れる形で送信されるのであれば厄介な話だなとおもって上で聞きました。
ただemacs-lisp自体はシングルスレッドなんですよね？
なので並列性に関しては心配していませんが、
平行性はどういう単位で実現されているのかで、問題の解決方法が変わってくるとおもいます。
|
 |
