在 Tcl 中,来自需要 Expect 的多个线程的 seg 错误

发布于 2024-09-06 22:55:39 字数 311 浏览 5 评论 0原文

现在有一些有趣的事情。当我在 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"

现在不是一个好时机。有什么想法吗?

Now here's something interesting. When I have more than one thread in Tcl invoking package require Expect, I get a seg fault.

e.g.

package require Threads  
package require Expect

set t [thread::create]

thread::send {package require Expect}

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

This is not a good time. Any thoughts?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

魂ガ小子 2024-09-13 22:55:41

Expect 和 Threads 并不能很好地结合在一起。它是从 fork() + 线程中获得的复杂性,可能会造成很大的影响并导致死锁和各种丑陋的情况。通常将两者结合起来并不是一个好主意。

如果您确实需要 Expect 和增加的并发性,那么使用多线程驱动程序和一个单线程 Expect 进程的多进程方法可能会更好。如果您使用 tcllibs comm 包,则用于发送命令的 api 也没有太大不同(如果您使用 comm,您大多会错过 tsv 和 tpool 的东西)。

但它肯定不会出现段错误。您使用了哪种 Expect/Threads/Tcl 核心组合(例如 ActiveStates ActiveTcl 捆绑包或不寻常平台上的一些自编译内容?)

Expect and Threads don't go together too well. Its the complexity you get from fork() + threads that can bite a lot there and lead to deadlocks and all kinds of uglyness. Usually not a good idea to combine the two.

If you really need Expect and the added concurrency a multi process approach with on multi threaded driver program and one single threaded expect process might work better. If you used tcllibs comm package the api's for sending commands are not that much different either (you mostly miss the tsv and tpool stuff if you used comm).

But it shouldn't segfault for sure. Which Expect/Threads/Tcl core combination did you use (e.g. ActiveStates ActiveTcl bundle or some self compiled stuff on an unusual platform?)

逆流 2024-09-13 22:55:41

全部来自最新的 debian 软件包,Ubuntu 9.0.4,64 位。

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

It's all from the latest debian packages, Ubuntu 9.0.4, 64 bit.

One alternative is to organize the code such that one thread is dedicated to handling all expect calls...which isn't the most elegant, generic solution but it might have to do.

盗琴音 2024-09-13 22:55:41

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

The C code of the expect library (loaded with package require Expect) is not thread-safe (it probably uses global variables or else). I tried a lot to work around this limitation because I wanted to have a load balancing algorithm based on the Thread library which would pilot some expect code launching builds on a pool of slave machines. Unless you are very good at C and want to enhance expect, I would rather suggest to launch expect interpreters (in their own OS process) each time you need to use it from your Thread-enabled program. But of course I don't know your problem to solve, and this would only work if the "expect works" are unrelated.. Good luck anyway..

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文