单元测试覆盖率不达到 100%，无法合并到主干，我们已经做到了。

@muziling 我先说一下我对题目的理解，就是有一个分布式作业系统，一个作业只能被一个 worker 执行，worker 可能会突然死掉，多个 worker 会抢占作业。

首先第一，作业需要有状态机

第二，为什么一个作业只能由一个 worker 执行，本质原因是这个作业所关联的资源（包括他自身的信息，如状态）只能由一个线程进行读写。那么可以解决资源的访问权限。

第三，确定状态转移的最大时间，就是 token 的超时时间，你可以依赖 token 超时保证不会再有其他线程在访问你的作业资源。

用 token
同一时间，只有一个 worker 获得有效 token
worker 可以利用 token 修改该 task 的状态和访问其相关资源

维权不只是为了开发者，更为了山寨品的 8000 多个付费用户，他们本来也想用正版软件，支持开发者，却被剽窃者欺骗。为了软件行业的健康发展，必须维权！作者可以众筹律师费

支持楼主

是否有联署的方式可以向 App Store 施压，下架 MPlayer X Pro 的应用？

你需要一个
type People interface { Hello() Sex() }

定义
type Male struct {
People
}
type Female struct {
People
}
分别实现 Sex 方法

如果想退款，需要先交 888 元保证金，后续会一并返还……

https://www.v2ex.com/t/286764 解释一堆名词有什么意义……

不同的 Level，看到的风景不一样罢了

简单来说，就是你的主线程需要等待日志写文件进程结束后才能结束。
写线程加个 wait chan 就好了

这种设计是有价值的，把 client 和 server 当作是一个节点上的 reciver 和 sender，就实现了一个并行处理服务了。利用多进程代替了多线程，从而可以方便进行调度管理。微信的后台就有类似这样的实现

PHP 继续深造是指学 C 吗？如果是，支持。
如果不是，那你还是换一种吧

explain 一下就知道啦

当前 Client 的序号是 x，Server 的序号是 y
Client Server
FIN_WAIT --seq=x+1,ack=y+1--> 未到达
CLOSING <--seq=y+1,ack=x+1-- FIN_WAIT
TIME_WAIT --seq=x+2,ack=y+2--> FIN_WAIT2

LZ 的猜想是，当 seq=x+1,ack=y+1 这个包比 seq=x+2,ack=y+2 的包晚到的时候，会不会出现 Server 变成了 FIN_WAIT2 状态。答案是不会！因为 Server 在等待 seq=x+1 这个包。等不到就会要求 Client 重传，直到收到 seq=x+1 这个包之后，seq=x+2 的包才有效。


@ysmood #15 和你说的什么应用层没关系，TCP 的有序是指能保证接收方接收数据包的顺序等于发送方发送的顺序

@xiadada #16 不知道你在说啥

“ tcp 的序列号字段只有在下面两种情况的任意一种才有意义：
1. 数据字段至少包含一个字节
2. 这是一个 SYN 段，或者是 FIN 段，或者是 RST 段 ”

这是谁跟你说的？

TCP 的有序性是依赖序列号和确认序列号保证的，哪有分什么阶段啊。还是翻出大学教材重新读一下，半小时，比你在这里问快多了。

@gutao1994 #8 补充一下，首先 TCP 里面的 seq （包的序列号）和 ack （应答序列号）确保了 TCP 通讯的有序性。如果你不清楚建议你再细读一下 TCP 协议。
然后你说的 fin 包延迟，是有可能发生的，假设没有接收窗口的情况下，client 的 ACK 包是不可能被接收的，因为他的序列号不对。如果有接收窗口的情况下，ACK 包会被接收到接收窗口里（可以理解成 buffer ），但是会等到 fin 包被接收后，有序地返回操作系统。

发送窗口和接收窗口了解一下

client 发出的 fin 包不会晚于它 ack 包到达 server （或者说被 server 确认接收）
why ？
因为 TCP 包是有序的啊