@FaceBug 对对对，这里你说的我赞同，劳动者可以选择留下来或者是拿赔偿。从楼主利益最大化的角度上来讲，我的建议就是仍然留在原来公司，毕竟产假时间很长。现在换工作的话，很难找到下家了。

现在来讲，问题主要是：

1. 楼主老婆怀孕时间不太合适；
2. 企业和员工都为了自己的利益，难免会有不同立场；
3. 交了生育保险，生育期间的工资和五险应该由有关部门发放和缴纳，但是要求劳动者必须连续缴纳足够月份的生育保险，企业只是保留之前岗位，是不是可以缓和这个问题。

@FaceBug 你这个依据的是劳动法二十六条，但是劳动法二十九条规定了怀孕期间是不允许根据二十六条解除劳动合同的

@mmqc 还有一点就是问老家是哪儿这个情况太常见了，你如果觉得这样是被“冒犯”的话，以后大概率还会被其他你新接触的同事“冒犯”到，他们不知道你会在乎这个的。

你这情况是我第一次见，我周围的同事的每个人的籍贯我都知道，没有人在乎这个不愿意说

仲裁几乎必赢的，不要怕。

@supermoonie 麻烦拉一下，多谢，Z29mYXJtZXI=

成功复现，确实好奇怪

@yianing 所以我提出的解决方案是缓冲区或者写的时候设置个超时

@yianing 这个超时问题关键在向 chan 写入的时候，读还未就绪，从而进入了 select 中的 default 选项；当读就绪的时候，chan 已经写入过了，从而阻塞在读取状态，直至超时，跟 Sleep 没太大关系啊。

@sunxiansong 这里的超时确实是使用 Context 包更好，但是框架的设计者不是这么做的，我们旨在解决请求未超时但是进入了 Timeout 的情况。我认为之所以出现了 false，是因为 SomeFunc 调度的时候，gotChan 还没有进入到读状态，这时候向 someChan 写入，会进入 default 逻辑，进而导致产生了超时。

@sunxiansong 我这个程序是对一个问题的抽象，可能抽象过度了，我说下原来的场景。

这个程序原来是在 `go SomeFunc(someChan)` 这一句发送了一个 tcp 请求，然后主程序进入等待响应阶段； SomeFunc 这个 goroutine 会执行 tcp 请求，并将结果写入 someChan 。SomeFunc 里的 `time.Sleep(10 * time.MicroSecond)` 是模拟的请求过程的请求时间。

这是我们使用的一个框架的底层源代码，我们发现了这个问题，并想着手解决，这就是前因后果，抱歉让你误解了。

@sunxiansong 你这个并不能解决返回 false 的问题啊，我现在是想搞清楚为什么返回 false 的问题，context 的 withTimeout 和 withDeadline 在这里并不影响问题的逻辑。

@whimsySun 问题只是缓解了，并没消除，退一步说这也不是解决问题的办法

@whimsySun 不行的啊，我试了一下仍然出现很多 false

@goofool 精度高了才会有上边的问题吧，你在自己电脑上跑一下看看是不是都是 true

建议手机厂商（ Apple 、华为、小米、OPPO 、vivo 、三星等） 在操作系统层面设置一个类似于定位开关的按钮，在不使用摄像头和语音的时候能关闭摄像头和录音权限。

楼上的说的基本上是对的，我也是这个思路实现的

gist.github.com/phpcyy/283bc10742b89e9daa908fc2c1270820

@wqlin 已经 commited 的日志一定是不会丢的，因为多数节点已经接收到了日志，所以只要这个系统还在工作，这个日志一定还是会在新的 Leader 上的。我之前的疑问是，一些老 Leader 没有 commit 的消息，其他节点也可能会将其 commit，因为他们无法区分老 Leader 是否提交了该日志。

@wqlin 你说的是对的，我省略了一些步骤，就是返回 client 成功的时候一定是 commited + applied 的。

我提出问题的时候想的是其他节点并不知道 Leader 已经 commited 且 applied，所以如何判断是否保存之前处于 uncommited 的消息。

现在看来是他们会由于日志更新而当选 Leader，并将该消息 commit 且 apply 。