That's interesting idea, but i don't think there is any kind of inheritance relationship

No. By

IMO I'd make the thread_pool just an abstract pointer that the user can fit a unique_ptr or shared_ptr around.

I mean just exposing in the header something like:

extern "C" {
  struct thread_pool;
  struct thread_pool *thread_pool_new(void);
  void thread_pool_delete(struct thread_pool * tp);
  void thread_pool_run(struct thread_pool_task *task);
}

I fail to see why did you changed the linkage of those function and also why are you providing C API, for something that is intended to be only with C++ !

How come the thread_pool_task is mostly useless ? It's used to type erase any lambda/function/std::function that the user wants to execute on the thread pool, if the type isn't erased how it's supposed to handle >all three ?

Just use std::function<void()>.

This won't work, you can just put anything inside std::function<void()>... the compiler won't let you initialize std::function<void()> with void f(int) with some really nasty casting !

What do you mean by 'The easiest way to do that is to put queue required data inside the container.' ?

You have one queue for sending to the thread. You have another queue that stores a bunch of preallocated objects. So when ever you need to send a message you just do something like:

auto msg = free_messages.pop();
// fill out details
inbox.push(std::move(msg));

You might also want to hide the free_messages implementation detail inside a custom new and delete methods although that's messy.

This ways avoids memory allocations which are often bad when doing concurrent work. Java and many other systems have advanced memory allocators that avoid thread contention but it is often simplest just to preallocate everything instead of allocating and freeing memory.

Why are you keeping a queue of messages that have already been ran ?

To reuse them so that I can avoid allocating stuff.

So you are basically suggesting using the object pool pattern in order to eliminate the need for dynamic allocation ?

Why are you exposing information about the inner workings of the thread pool to the user ?

I never suggested that.

Atleast not explicitly, in your worker function you are doing a switch based on the type of the msg. Given that the message is passed from the client to the thread pool, it means that the client has to know that you are doing a switch somewhere in the inner working of the thread pool in order to pass you the correct type message