When and how is the thread pool cleaned up?

[awakecoding]

I am new to libuv, and the first thing I am trying to implement is a cancellable getaddrinfo that can cleanup after itself once cancelled. Looking at the code and documentation, I found out that getaddrinfo is implemented as a work item executed in a thread pool. Since cancellation fails on an item that is currently executing, it means that I cannot free associated memory until it finishes executing. I could work around the problem by creating a loop and associated handles that would remain valid for the duration of the process, but then I do not know when and how it could be properly freed. I couldn't find in the code a clear part that would close and cleanup the thread pool when the process terminates. How is this currently handled? What happens if I queued a custom work item that sleeps forever, and therefore would never be cancellable? Thanks!

[bnoordhuis]

The thread pool is shut down at program exit or when libuv.so is unloaded.

What happens if I queued a custom work item that sleeps forever, and therefore would never be cancellable?

It ties up the thread indefinitely. The program too because libuv tries to reap the thread on exit.

[awakecoding]

@bnoordhuis thanks for your quick reply, I found the cleanup function that gets called on program exit. If a work item gets stuck forever, does this mean that I can't free the associated uv_loop_t and uv_work_t explicitly during the program execution (and before the cleanup function is called)? I need to queue my work from different threads, I don't know if reusing the default run loop is a good idea for thread safety. In my current code, I create a new uv_loop_t for a new uv_getaddrinfo_t. I could change it to use a singleton uv_loop_t instead. I guess I could check at program close if no pending work items remain in the queue, and leak it if there are still pending items.

[bnoordhuis]

If a work item gets stuck forever, does this mean that I can't free the associated uv_loop_t and uv_work_t explicitly during the program execution (and before the cleanup function is called)?

That's right.

I don't know if reusing the default run loop is a good idea for thread safety

Nope, not thread-safe.

[davisjam]

@awakecoding Cancelling work that has been assigned to a worker will become possible from the embedder side if libuv #1726 gets traction. However, depending on the work being performed, cancellation may not be safe.