gopl-zh ch8问题反馈

[cch123]

RT
有问题在这里提出，会尽快修正

[bluebanboom]

8.7 的gopl.io/ch8/countdown1例程中的
j <- tick
应该是
<- tick

[cch123]

@bluebanboom ，已修正~

[dreamrover]

8.4 正文第三段：因此调用者何（和）被调用者将引用同一个channel对象
8.4 正文第四段：如果两个channel引用的是相通（同）的对象
8.4 正文第六段：对一个已经被close过的channel之（进）行接收操作
8.4.3 正文第二段：但是它们的使用方式想（相）反
8.4.3 正文第三段：当一个channel作为一个函数参数是（时）
8.4.4 正文倒数第九段：但是在真是（实）的程序中它们一般由不同的goroutine执行
8.4.4 正文倒数第四段：然后在（再）加快赶上进度而不影响其他人
8.7 正文第七行：下面这个例子更微秒（妙）

[cch123]

@dreamrover ，感谢！
很细致的纠错~
都已经修正啦

[dreamrover]

又发现一些：
8.4节：
第一段：一个channels是一个通信机制——应该去掉“s”
正文第三段：channel也一个对应（对应一个）make创建的底层数据结构的引用
正文第五段：发送和接收两个操作都是（使）用<-运算符
正文第六段：如果channel中已经没有数据的话讲（将）产生一个零值的数据。
正文第八段：以最简单方式调用make函数创建的时（是）一个无缓存的channel，但是我们也可以指定第二个整形（型）参数

8.4.1节 倒数第三段：
关闭网络链（连）接中的写方向的链（连）接将导致server程序收到一个文件（end-of-file）结束的信号。关闭网络链（连）接中读方向的链（连）接将导致后台goroutine的io.Copy函数调用返回一个“read from closed connection”（“从关闭的链（连）接读”）类似的错误……这（是）Go语言中启动goroutine常用的形式

8.4.2节：
第一段：Channels也可以用于将多个goroutine链（连）接在一起，一个Channels的输出作为下一个Channels的输入。——后面两个Channels的“s”应该去掉
// Squarer 代码下面那段：而且这种处理模式很场景（常见）

8.4.3节：
第一段：然后用两个channels连链接（来连接）它们
第二段：其中squarer计算平方的函数（计算平方的squarer函数）在两个串联Channels的中间，因此拥有两个channels（去掉s）类型的参数……每（两）个channels都用有相同的类型……但是并无法保证squarer函数向一个in参数对应的channels（去掉s）发送数据或者从一个out参数对应的channels（去掉s）接收数据。
最后一段：也就是不能一个将（将一个）类似chan<- int类型的单向型的channel转换为chan int类型的双向型的channel。

8.4.4节：
Figure 8.4上面那段：因此对该channel执行的发送或接收操作都不会发送（生）阻塞
倒数第六段：创建一个对应容量大小（的）带缓存channel也是不现实的
倒数第二段：或者是无法满足第（三）阶段厨师的需求——漏了个“三”

[dreamrover]

8.5节：
正文第三段：并且是最能够享受并发带来的好处——去掉“是”

正文第五段：没（每）一个文件名对应一个

makeThumbnails5代码之后第二段：这个计数器需要在多个goroutine操作时做到安全并且提供提供在其减为零之前一直等待的一种方法——多了一个“提供”

正文倒数第二段：

观察一下我们是怎样创建一个closer goroutine，并让其等待worker们在关闭掉sizes channel之前退出的。

——没表达清楚，这样翻译应该更好：

观察一下我们是怎样创建一个closer goroutine，并让其在所有worker goroutine们结束之后再关闭sizes channel的。

[cch123]

@dreamrover ，本章已修正~

[jau1jz]

8.4.2最后一段 "视图重复关闭....... , 视图关闭" 应该为试图

[cch123]

@jau1jz，你看的不是新版

[stepdc]

8.6 主函数和5.6节中的breadthFirst(深度优先)类似。 -->广度优先

[cch123]

@stepdc ，thx。。已修正，这个译错是我的，好低级orz

[klifish]

ch8-04-2，倒数第二段，第二句：“只要”应该改为“只有”才通顺，请斟酌，谢谢！

[cch123]

@klifish ，thx，已修正

[klifish]

就直接提了：
8.4.3
最后一段，第一句
---->调用counter（naturals）时，naturals的类型将隐式地从chan int转换成chan<- int

8.5
因为我们已经知道内部的goroutine只有len(filenames)
---->因为我们已经确切地知道有len(filenames)个内部goroutine

8.6
这是为了避免在main goroutine和crawler goroutine中同时向另一个goroutine通过channel发送内容时发生死锁(因为另一边的接收操作还没有准备好)
----> 这是为了避免channel两端的main goroutine与crawler goroutine都尝试向对方发送内容，却没有一端接收内容时发生死锁

这里的n是fd的limit-20
---->这里的n一般小于文件描述符的上限值，比如20

另外，关于long-lived的翻译，借用了一下这里的讨论，译为“常驻”颇为合适。

[cch123]

@klifish , thx! 已修正

[bianchui]

标题
8.8. 示例: 并发的字典遍历
这个应该是目录遍历

[cch123]

@bianchui , thx, fixed

[cch123]

@zengming00 ，只要没有在监听 ch 的 goroutine 就没事，不过技术问题还是找专门的论坛讨论比较好，这里主要是反映书里的错误的~

[chai2010]

ch为空没问题，runtime会回收资源，最多是goroutine会浪费一些cpu。如果不想浪费可以试试context包。话说代码简单也是很有意义的，不要太吝啬cpu，除非这种错误经常发生

[chai2010]

@zengming00 对于这种不影响大局的问题，指望别人改是不靠谱的。如果你觉得确实有注释的必要，可以自己尝试去提交一个PR，这样被接受的机率会大很多

[cch123]

@zengming00 ，我的意思是去技术社区讨论可以把内容沉淀下来，比如gocn.io，不过也确实如柴大所说，如果你觉得有问题，提一个 pr 补一个译注也挺好的，我们看没问题的话会给合并

另外我们这里毕竟只是翻译，补充一些译注也是依照译者的理解和风格去加，如果原作者没有写的东西。。指望译者都能补全有点难啊。。

另外，就这里说的这个技术问题，函数退出之后 chan 不排空问题也不大，之后 chan 会被 GC 掉，只要没有 goroutine 在监听就可以

[corberan]

8.4.1 Unbuffered Channels

第二段最后一句：
原文：When a value is sent on an unbuffered channel, the receipt of the value happens before the reawakening of the sending goroutine.
翻译为：当通过一个无缓存Channels发送数据时，接收者收到数据发生在唤醒发送者goroutine之前。

reawakening一词翻译为唤醒好像不太准确，“再次唤醒/重启”可能好一些，毕竟是reawakening不是awakening，而且会让人费解，唤醒发送者goroutine之前接收者为什么会收到数据？考虑到对无缓存channel，相应的接收在重新唤醒发送goroutine之前完成应该合理。不知道我的理解是否正确。

[cch123]

@liuz430524，按你的建议修改了一下，再次唤醒

[panchengtao]

8.4.2 小节倒数第二段
（不要将关闭一个打开文件的操作和关闭一个channel操作混淆。对于每个打开的文件，都需要在不使用的使用调用对应的Close方法来关闭文件。）

“不使用的使用”是否应该改为“不使用的时候”？

[cch123]

@wddpct ，你看的是老版本，仓库中的是比较新的了

[panchengtao]

@cch123 我看的是gitbook版本，不过谢谢了