Introduce uv_threadpool_t

[saper]

This is a very quick'n'dirty
attempt to introduce more
explicit threadpools, as discussed
in libuv/leps#4
and #267

If more customization of the threadpool
is required (struct uv_threadpool_s)
can be expanded to include pointers
to functions doing the real work.

Names are ugly right now; C99 struct initialization
required.

[saghul]

This is a very quick'n'dirty
attempt to introduce more
explicit threadpools, as discussed
in libuv/leps#4
and #267

Thanks for taking the time to write this! This is not exactly what I had in mind, because it's not a handle, but it did give an idea.

We could add the threadpool handle / customexecutor (to accomodate @bnoordhuis's use case with V8 workers) as a new handle, but keep using the current global threadpool for fs and dns operations in the v1.x branch. This new threadpool handle's implementation is very similar to the current one, but contained in a handle, and thus, not thread-safe. (right now there is a global lock because any loop can queue work in the one and only thread pool).

As a result, we'd "deprecate" uv_queue_work and encourage people to create their own pools and queue work there, in order to avoid starving the default one.

There would be some code "duplication" (not really duplication, but it would be very similar), but it would pave the work for explicitly requiring the pool for fd and dns requests in the future.

If more customization of the threadpool
is required (struct uv_threadpool_s)
can be expanded to include pointers
to functions doing the real work.

This needs to be thought out before the implementation, since v1.x is ABI stable.

Names are ugly right now; C99 struct initialization
required.

No can do, libuv is C89.

[saghul]

I'll sleep over it and amend the LEP with the new idea.

[saghul]

We had a "summit" where we planned out features for v2. This was discussed, and we decided to go with the approach roughly described in #267. @bnoordhuis will be writing a LEP on the matter.

Sorry this was kept open so long, and thanks for your willingness to help out.

[saper]

@saghul thank you, this was just a sketch. I actually think now that introducing coroutines instead of thread pools will be much more powerful. I'll try to describe what I mean soon.