1

ここで興味深いことがあります。を呼び出す Tcl に複数のスレッドがpackage require Expectあると、seg fault が発生します。

例えば

package require Threads  
package require Expect

set t [thread::create]

thread::send {package require Expect}

puts "blarg! Damned thing crashes before I get here"

これは良い時期ではありません。何かご意見は？

4

3 に答える 3

2

Expect と Threads はあまりうまく連携しません。fork() + スレッドから得られる複雑さは、そこに多くの食い込みがあり、デッドロックやあらゆる種類の醜さを引き起こす可能性があります。通常、この 2 つを組み合わせることはお勧めできません。

Expect と追加の並行性が本当に必要な場合は、マルチスレッド ドライバー プログラムと 1 つのシングル スレッドの Expect プロセスを使用したマルチ プロセス アプローチの方が適切に機能する可能性があります。tcllibs comm パッケージを使用した場合、コマンドを送信するための API もそれほど違いはありません (comm を使用した場合、ほとんどの場合、tsv と tpool の機能が失われます)。

しかし、それは確かにセグメンテーション違反であってはなりません。どの Expect/Threads/Tcl コアの組み合わせを使用しましたか?

于 2010-06-26T15:03:53.970 に答える
0

これはすべて、最新の debian パッケージ、Ubuntu 9.0.4、64 ビットのものです。

1 つの代替手段は、1 つのスレッドがすべての Expect 呼び出しの処理専用になるようにコードを編成することです...これは、最も洗練された一般的なソリューションではありませんが、そうする必要があるかもしれません。

于 2010-06-27T10:59:18.833 に答える
0

expect ライブラリ ( でロードされるpackage require Expect) の C コードは、スレッドセーフではありません (おそらく、グローバル変数などを使用します)。私はこの制限を回避するために多くのことを試みましたThread。これは、スレーブ マシンのプールでコードを起動するビルドをパイロットするライブラリに基づく負荷分散アルゴリズムが必要だったからです。C が得意で、expect を拡張したい場合を除き、Thread 対応プログラムから使用する必要があるたびに、expect インタープリターを (独自の OS プロセスで) 起動することをお勧めします。しかし、もちろん、解決すべき問題はわかりません。これは、「期待される作品」が関係ない場合にのみ機能します..とにかく頑張ってください..

于 2010-07-02T14:03:47.430 に答える