Closed fesily closed 1 year ago
这个问题应该有更好的方案 比如说加入一个全局环境变量context,每次attach都是新建一个context,除了这个变量不使用任何其他全局变量.
首先先把问题拆分成两个
对于问题2,目前的代码应该还差很多,暂时可以不考虑。 对于问题1,首先launcher需要有地方确保多次调用launcher是针对同一个lua模块。然后我觉得start应该是要允许多次调用,我们应该把现在还不能并发的地方改掉。
最后waitdll也确实可以限制它全局唯一实例,因为同时调用多个waitdll似乎也没什么意义。
首先先把问题拆分成两个
- 对同一个lua模块,多次调用launcher
- 对不同的lua模块,多次调用launcher
对于问题2,目前的代码应该还差很多,暂时可以不考虑。 对于问题1,首先launcher需要有地方确保多次调用launcher是针对同一个lua模块。然后我觉得start应该是要允许多次调用,我们应该把现在还不能并发的地方改掉。
最后waitdll也确实可以限制它全局唯一实例,因为同时调用多个waitdll似乎也没什么意义。
start并发需要,有一个固定的gum::interceptor
,不然会重复hook
想要保证同一个module_path,那就得存一下,之前的结果.
那其实应该加一个全局变量
👌,测试了一遍
同一个lua模块的watchdog,应该是可以复用的。或者说,第二次attach,launcher应该什么都不需要做。
同一个lua模块的watchdog,应该是可以复用的。或者说,第二次attach,launcher应该什么都不需要做。
hook还是要做的,其他的可以不做
现在master线程在进程退出前,应该都是不会退出的。所以第二次attach,其实只需要直接connect上一次attach已经创建出来的master线程就可以了。
现在master线程在进程退出前,应该都是不会退出的。所以第二次attach,其实只需要直接connect上一次attach已经创建出来的master线程就可以了。
worker对象还是退出了吧,光连接上master没有用吧
worker应该也没有退
worker应该也没有退
我测试看看
的确可以
有空reveiw一下
但是对于luadebug不能彻底卸载的问题,我觉得需要提供一个方案来提供优雅退出,现在等于说管杀不管埋.
我觉得没有必要,甚至DAP也没有结束调试器但不退出进程的协议。 如果自己驱动update事件的话,在调试器前端不存在时,调试器后端对调试目标就是零影响。
我觉得没有必要,甚至DAP也没有结束调试器但不退出进程的协议。 如果自己驱动update事件的话,在调试器前端不存在时,调试器后端对调试目标就是零影响。
但我的想法一直都是需要释放掉产生资源的. 因为除了手机和电脑不在乎内存使用的大小,单片机上能用的内存很小的.以mb计算.
对于调试器而言,当你不需要它时,最直接的办法是不加载它,甚至不要带上调试器二进制和代码。
与其考虑luadebug的退出,不如先解决launcher退出的问题。因为launcher有hook,它的退出更有意义。
现在launcher的退出时机,需要luadebug提供,所以launcher需要导出一个函数给luadebug, 这个函数可以将launcher的一个luamodule退出,当所有的luamodule都已经退出后,launcher可以将自己退出。
与其考虑luadebug的退出,不如先解决launcher退出的问题。因为launcher有hook,它的退出更有意义。
现在launcher的退出时机,需要luadebug提供,所以launcher需要导出一个函数给luadebug, 这个函数可以将launcher的一个luamodule退出,当所有的luamodule都已经退出后,launcher可以将自己退出。
这个功能我已经考虑过了,等现有的功能先合并完了,在做一个
@fesily 还有些错误,lua_newstate的第一个参数不是L
@fesily 还有些错误,lua_newstate的第一个参数不是L
嗯,下午我改下
waitdll的时候,出现以下情形: 上一次attach的处理流程还在waitdll. 又主动attach进来,导致两个线程在跑start函数.
当前launcher不是纯粹的无状态的代码,有竞态条件的
添加一个全局环境变量