支持 unlimited 池子大小

[choleraehyq]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
考虑一个情况，当池子运行的函数本身，又需要调用这个池子投放新的任务时，是有死锁的可能的。从使用层面上这个问题很难避免，但是如果池子本身不限制大小，就能避免死锁。

Describe the solution you'd like
A clear and concise description of what you want to happen.
支持不限制池子大小的功能。

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
这很难，需要使用者小心谨慎地使用池子，保证没有同一个池子的嵌套。

Additional context
Add any other context or screenshots about the feature request here.
限制并发数的功能完全可以在上层实现，所以没什么损失。

[panjf2000]

往 Pool 里投放任务的时候加锁也就是在获取可用 worker 的期间，获取到 worker 之后锁就释放了，任务执行期间是无锁的，所以就算是嵌套使用 Pool 也不会发生循环等待，不应该会有死锁吧？

[panjf2000]

我捋了一下，你说的应该是 worker 在执行嵌套使用 Pool 的任务之时，Pool 满了之后 worker 一直等待自身完成的死循环吧，这个的确是一个潜在的问题。

不过我在想，既然 Pool 都没有限制了，那为什么不直接不用 Pool 呢？无限制的 Pool 本身的概念是有点自相矛盾的。

[choleraehyq]

@panjf2000 并不矛盾，pool 是用来复用 goroutine 的，而不完全是用来控制并发的。

[panjf2000]

也有道理，我找时间做一下。

[choleraehyq]

@panjf2000 看了下改动，跟 Tune() 接口是不兼容的？

[panjf2000]

什么意思？你还想通过 Tune(int) 把 unlimited 给 revert 了？

[choleraehyq]

文档里并没说 Tune 跟 unlimited 怎么交互啊。没准会有人用 Tune 搞一个负数。

[panjf2000]

哦，你是说想通过 Tune 来把一个普通的 pool 设置成 unlimited，这个我觉得还是不要支持了，unlimited 特性就只通过 NewPool 这一个唯一的入口来设置，规范一点。
我等下在补充一下 Tune 的说明，把 unlimited 的设置说一下。

[panjf2000]

我又想了一下，支持通过 Tune 来设置 unlimited 似乎会灵活很多，也没我之前想的那样可能会导致很多问题，所以我决定还是支持调用 Tune(size int) 来控制 unlimited 特性，size <= 0 就把 pool 设置成 unlimited，size > 0 则把 unlimited pool 变回普通的 pool

[panjf2000]

改完测试了一下，发现了还是有坑，Tune 把 unlimited pool 改成普通 pool 还好，但是反过来的话，如果当前已经有因为之前的 capacity 满了而阻塞住的 Submit，Tune 成 unlimited pool 之后，只对那些新的 Submit 生效，这些阻塞的 Submit 却还是会一直等到有空闲的 worker 才能返回，还是会有这些潜在的问题，所以暂时还是不支持了。