В Tcl ошибки сегмента от нескольких потоков требуют Expect

Question

Теперь вот кое-что интересное. Когда у меня в Tcl более одного потока, вызывающего package require Expect, я получаю ошибку сегмента.

, например

package require Threads  
package require Expect

set t [thread::create]

thread::send {package require Expect}

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

Это не хорошее время. Есть мысли?

Answer 1

Expect и Threads не слишком хорошо сочетаются друг с другом.Это сложность, которую вы получаете от fork () + потоков, которые могут сильно кусаться и приводить к тупикам и всевозможным уродствам.Обычно не рекомендуется объединять их.

Если вам действительно нужен Expect и дополнительный параллелизм, многопоточный подход к многопоточному драйверу и один ожидаемый многопоточный процесс могут работать лучше.Если вы использовали пакет tcllibs comm, то API для отправки команд также не сильно отличаются (в большинстве случаев вы пропускаете tsv и tpool, если вы используете comm).

Но это не должно обязательно вызывать сегфоКакую комбинацию ядра Expect / Threads / Tcl вы использовали (например, пакет ActiveStates ActiveTcl или что-то само скомпилированное на необычной платформе?)

Answer 2

Код C библиотеки ожидаемых данных (загруженный с package require Expect) не является поточно-ориентированным (вероятно, он использует глобальные переменные или другое). Я много пытался обойти это ограничение, потому что хотел иметь алгоритм балансировки нагрузки, основанный на библиотеке Thread, который позволял бы запускать некоторые ожидаемые сборки запуска кода на пуле подчиненных машин. Если вы не очень хорошо разбираетесь в C и не хотите повышать ожидания, я бы предпочел запускать ожидаемые интерпретаторы (в их собственных процессах ОС) каждый раз, когда вам нужно использовать их из вашей программы с поддержкой потоков. Но, конечно, я не знаю, какую проблему решить, и это сработает только в том случае, если «ожидаемые результаты» не связаны .. В любом случае, удачи ..

Answer 3

Это все из последних пакетов Debian, Ubuntu 9.0.4, 64-битная.

Одна альтернатива - организовать код так, чтобы один поток был выделен для обработки всех ожидаемых вызовов ... что несамое элегантное, универсальное решение, но, возможно, придется сделать.