本文主要是介绍EDA - s家的dc_shell-t read缓冲区大小不同引起的问题，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
EDA - s家的dc_shell-t read缓冲区大小不同引起的问题
问题描述
在CentOS 7上执行dc_shell-t -topo -64bit进入shell后，source /path/to/tcl.tl，还在source的过程中使用另一台服务器执行svn up /path/to/tcl.tl，接着该source过程就报错退出。而在CentOS 6上该flow是能正常完成的。
问题分析
testcase
人工写一个/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"
test
分别在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一次性将脚本内容读进内存，然后开始执行。
解决方案
- 在跑该flow过程中，
尽量不使用任何方式更新正在跑的文件； - 假设不可避免要更新正在跑的文件，则可以在同一台机器上更新它。
因为同一台机器更新NFS的文件时，正在被open的原inode的文件rename成.nfs*****这样的文件，原来的file handle就还有效，这样flow就不会报错退出； - 假设不可避免要更新正在跑的文件，
则可以使用花括号将全部业务逻辑包起来，让解析器认为它属于同一个语句块，以便一次性加载到内存中；
TO-DO
需要与厂商确认，看6与7上，为何工具的同一个命令调用的系统调用read，buffer size传参值却不一样。
写在后面
dc_shell使用的是原生格式的厂家特定语言，而dc_shell-t使用的是标准的tcl语言格式。
资料参考
https://link.springer.com/chapter/10.1007%2F0-306-47507-3_3
https://zhuanlan.zhihu.com/p/129059203
这篇关于EDA - s家的dc_shell-t read缓冲区大小不同引起的问题的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
