在CentOS 7上执行dc_shell-t -topo -64bit
进入shell后,source /path/to/tcl.tl
,还在source的过程中使用另一台服务器执行svn up /path/to/tcl.tl
,接着该source过程就报错退出。而在CentOS 6上该flow是能正常完成的。
人工写一个/path/to/tcl.tl,里面内容为
#!/usr/bin/tclsh after 2000 puts "echo point 01" after 2000 puts "echo point 02" ## ... 100 times here, snippet ommitted ... ## after 2000 puts "echo point 02"
分别在CentOS 6与CentOS 7上启动dc_shell-t,按照问题描述中的flow走,发现在6上确实没问题,在7上会报错
information: script "/path/to/tcl.tl": stopped at line 100 due to EOF
于是在走flow前,分别在6和7上都使用strace命令追踪dc_shell-t进程,然后开始走flow。经查看strace日志发现,
OS | dc_shell-t’s read buffer size | tcl脚本读取与执行顺序 |
---|---|---|
CentOS 6 | 65536 | read一次就执行一次。循环往复,直到内容被读完执行完。 |
CentOS 7 | 8192 | 同上 |
检查被source的/path/to/tcl.tl脚本,大小为10000多字节。对照上面的表格,可以看出在6上可以一次被load进内存并执行,而在7上则先load前面的8192字节,待执行完后再load剩余部分。由于在第一次执行期间,该脚本就被另一台机器执行svn up更新了。虽然文件还在,但更新后的文件inode变了,原inode丢失了,内核中维护的file handle失效,变成了Stale file handle。当dc_shell-t再次要读取剩余脚本时遭遇了Stale file handle,报错EOF并退出。
为了对照,我又运行tclsh 8.6.11解析器,来看看原生的tcl的行为
OS | tclsh’s read buffer size | tcl脚本读取与执行顺序 |
---|---|---|
CentOS 6 | 4096 | 多个read一次性将脚本内容读进内存,然后开始执行。 |
CentOS 7 | 4096 | 同上 |
在测试时,发现如果使用if分支的花括号,将大于buffer size的内容包进来,在测试时dc_shell-t也会有像tclsh一样的行为:同一个语句块内的内容将被多个read一次性将脚本内容读进内存,然后开始执行
。
https://link.springer.com/chapter/10.1007%2F0-306-47507-3_3
https://zhuanlan.zhihu.com/p/129059203