About thread pool

[esowt]

questions:

1. any plan to support dynamically scalable thread pool?
2. if not, how to solve slow NFS IO?
3. why not expose uv__work_kind to API?
4. I can not find any support for file lock

for heavy file IO, the golang kernel may open many threads to do it on runtime

[bnoordhuis]

any plan to support dynamically scalable thread pool?

Not at the moment. I created libuv/libuv#382 but it ended up not getting merged.

One big problem with auto-scaling is that a common setup for libuv programs is multiple processes, each with its own thread pool.

In that configuration it's impossible to heuristically determine the optimal thread pool size.

if not, how to solve slow NFS IO?

Not a super clear question but I think you're looking for the UV_THREADPOOL_SIZE environment variable?

why not expose uv__work_kind to API?

Unclear question. Let me invert that: why not not?

I can not find any support for file lock

There isn't any. Portable file locking is pretty much impossible. http://0pointer.de/blog/projects/locking.html has a good overview of the problems.

[esowt]

Not a super clear question but I think you're looking for the UV_THREADPOOL_SIZE environment variable?

I have read the source code, and It looks like I can only use setenv to adjust it before thread initialization, and MAX_THREADPOOL_SIZE is actually a hard-coded value

usually, we will determine the initial number of threads based on the number of CPU cores

In that configuration it's impossible to heuristically determine the optimal thread pool size.

many other languages ​​have implemented scalable thread pools, in my opinion, their basic idea is
if (all threads are blocking on slow_io) thread_pool.extend();
if (thread.idle_time > thread.keep_alive_time) exit();
now machine performance is getting stronger, and memory is getting cheaper, It should not be unacceptable to start a large number of threads.

if not, how to solve slow NFS IO?

libuv always assumes that file IO is fast, but in fact it may block for quite a long time
that is why I want to have a dynamically scalable thread pool

why not expose uv__work_kind to API?

uv_queue_work is regarded as CPU intensive operation, maybe sometimes I want to submit a slow IO operation?

about flock

sometimes we hope that: it can be difficult to use, but it cannot be absent
how do we solve the problem of writing log file in multiple processes?

🥺 Thank you for your answer

[bnoordhuis]

determine the initial number of threads based on the number of CPU cores

That's what I mean: with multi-process setups that ends up spawning num_cpus * num_processes threads.

With I/O-heavy workloads that might be okay (most threads will usually spend most of their time blocked in system calls) but it's almost certainly not what you want for CPU-intensive workloads.

That's also why it's configurable through an environment variable and not programmatically: the system administrator or end user has a better, more holistic view of the optimal size than the application programmer.

I'm not completely opposed to adding a programmatic API but when people requested that in the past it was always for the wrong reasons.

many other languages ​​have implemented scalable thread pools

I think you're conflating language or runtime with library here. Libuv is a library, not a runtime.

libuv always assumes that file IO is fast

Right, I understand what you mean but the current fast/slow I/O divide is a bit of a bandaid to fix thread starvation.

It's not the final word on how libuv will handle that going forward and I don't think we want to expose that kind of implementation detail in the public API.

how do we solve the problem of writing log file in multiple processes?

A fairly simple and robust approach is to have a secondary file that you create with UV_FS_O_CREAT|UV_FS_O_EXCL and functions as a kind of inter-process mutex.

How to implement fairness is left as an exercise to the reader. :-)

[esowt]

I think you're conflating language or runtime with library here. Libuv is a library, not a runtime.

the kernels of some languages ​​are heavily rely on the libraries they use
after all, we always hope that the library can help us solve most of the problems : )

your answer is clear enough, thanks again for your help!