ddid帮我分析一下这个
....前面是dubook，然后等读完locall,w=wait.regexp("^[>\\s]*你(?:研读完毕|收起手上的)",300)
if l~=nil and string.find(l,"研读完毕") then
print("OK,成功")
end
循环体中这样一个chunk，在执行中，当研读完毕时，有时打印出成功，有时明明是研读完毕却没打印出来。显然是哪个地方出了问题，为了跟踪问题，我修改了wait.lua，将wait中的trigger_resume改成这样子。
function trigger_resume (name, line, wildcards, styles)
local thread = threads
if thread then
threads = nil
local ok, err = coroutine.resume (thread, line, wildcards, styles)
if not ok then
ColourNote ("deeppink", "black", "Error raised in trigger function (in wait module)")
ColourNote ("darkorange", "black", debug.traceback (thread))
error (err)
end -- if
else
print(name," resume, got \"",thread,"\" thread")
end -- if
end -- function trigger_resume
你猜怎么着，嘿，当出现问题时，还真打印出来 wait_trigger_1884065resume, got " nil " thread。也就是说，当这个trigger被触发，需要resume时，找不到这个线程了。找不到线程，自然就执行不下去了。什么原因呢？ 有点意思，等等我测试一下。 我不知道，这个与同时运行多个mushclient rbt有关么？ 注意观察了一下wait.regexp即使是在进程结束后也不释放内存，这样当thread不断增多以后，最后会溢出。 这个好象有道理，我如果是两个窗口都忙着的时候，空线程的概率明显加大 一个印象，频繁的使用wait.make()创建进程，不是一个好的编程习惯。
还是建议myu改变思路，虽然都知道wait.regexp好用，但是也是有一定的条件限制的。看起来你的环境不太适合这么用。 如果不用regexp的话，好象又回到了zmudttk_13
频繁是肯定的，不过，我在任务调用之前都加上一个DoCommand(ReloadScriptFile)，看来mushclient的这个机制是存在问题。 其实分析一下wait.lua中的regexp()，这部分也就是用了AddTriggerEx()，另外通过coroutine包装一下,来控制时间，如果是频繁调用，不如自己用AddTriggerEx()和DoAfterSpicial()实现，至少没有coroutine的问题。 造成这种情况的直接原因，是wait.lua中的thread表。在挂起当前线程的时候，wait将线程变量保存在个表中，可是当需要resume的时候，却在这张表中找不到这个变量了。为什么会出现这个情况，有两个可能性，第一个可能的原因是这个变量被另外的进程释放掉了，我经过跟踪，没有发现多个线程使用同一个ID的情况，既然ID是唯一的，那就不会被别的线程释放。第二种可能性就是wait.lua这个文件被重新装载了，重新装载，做为其局部变量的thread表当然就清空了，这也就找不到原来的线程。这个可能性最大，我检查了程序，这其中并没有显式地使用DoCommand("ReloadScriptFile")，那么是什么原因导致thread表覆灭呢。也许，我把这个thread表定义为全局变量试试。 呵呵，我等着看结果哦，小白鼠～