do you want to use low level solution and implement your own worker pools etc? or do you just want a solid solution? because if it's rust -> actix is an actor concept that abstracts the problem in the same way erlang for example does it.
actors pass messages to each other and you haven an arbiter that spawns your actors if you send the message to them.
about concurrency there are so many solutions. thread pool just means spawning a certain amount of threads and push things via queue / buffer towards them.
a more efficient way would be using the kernel event loop in my opinion. maybe reading the node stream implementation would help in your particular problem?
I just programmed different solutions in different languages / concepts and for fun I read the scientific papers. I don't have a practical guide or good talk about concurrency beside the jepsen ones but they are about the consequences rather than the implementations.
It's also very language dependent, go/node for example make concurrency super easy, C/C++ can make it a pain in the ass. Java/Rust/C# give you different threading models, Erlang uses it's own process infrastructure in the VM, ... The idea however always remains the same
package your input - pass it on - if you can don't use shared memory within the thread.
if you use buffered reader that are threadsafe or if you use an in memory database that just checks for concurrency.
The first question I would ask myself is about order ... a CSV for example does not need to be processes in a specific order a book however does.
But you probably know all of this.