1

现在这里有一些有趣的东西。当我在 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"

这不是一个好时机。有什么想法吗？

4

3 回答 3

2

Expect 和 Threads 不能很好地结合在一起。它从 fork() + 线程中获得的复杂性可能会在那里咬很多东西并导致死锁和各种丑陋。将两者结合起来通常不是一个好主意。

如果您真的需要 Expect 和增加的并发性，那么在多线程驱动程序上使用多进程方法和一个单线程期望进程可能会更好。如果您使用 tcllibs comm 包，则用于发送命令的 api 也没有太大不同（如果您使用 comm，您通常会错过 tsv 和 tpool 的东西）。

但它肯定不应该出现段错误。您使用了哪个 Expect/Threads/Tcl 核心组合（例如 ActiveStates ActiveTcl 包或一些在不寻常平台上自编译的东西？）

于 2010-06-26T15:03:53.970 回答
0

这一切都来自最新的 debian 软件包，Ubuntu 9.0.4，64 位。

一种替代方法是组织代码，使一个线程专用于处理所有期望调用……这不是最优雅、通用的解决方案，但它可能必须这样做。

于 2010-06-27T10:59:18.833 回答
0

期望库的 C 代码（用 加载package require Expect）不是线程安全的（它可能使用全局变量或其他）。我尝试了很多方法来解决这个限制，因为我希望有一个基于Thread库的负载平衡算法，它可以在从机池上试运行一些预期的代码启动构建。除非您非常擅长 C 并且想要增强期望，否则我宁愿建议每次您需要从启用线程的程序中使用期望解释器（在他们自己的操作系统进程中）时启动它。但是，我当然不知道您要解决的问题，而且只有在“预期工作”不相关的情况下才有效。无论如何祝你好运..

于 2010-07-02T14:03:47.430 回答