Threadpool for incoming connections

[LukasKalbertodt]

Currently a new thread is created for every incoming connection. Reusing old threads would improve performance.

It would be useful to do some research on what type of thread pool to use:

• Fixed size (probably bad: Refusing connections, if no thread is available)
• Just growing (probably bad: Many paused threads)
• growing and shrinking

[Cranc]

Got a question in regards to this
would a system like that not be better (have no idea how much work it actually would be)

Client sends login request
server accepts login if correct and keeps track of people that are logged in but does not give them a thread yet

client sends a request in combination with his user information

since the server took note that the client already logged himself in he then opens a thread for the request returns the result and kills the thread again (cause its not needed any-more)

only downside for that is the fact to determine when someone is logged out when no logout message is send from the client and even that could be handled with time-outs

[SvantjeJung]

Found this two:

• threadpool
• scoped_threadpool

I haven't quite understood if the pool can grow with both crates, looks like they are created with a fixed size. But shrinking may be implemented by the first crate mentioned: ''Spawns n worker threads and replenishes the pool if any worker threads panic.''

[Cranc]

as far as i understood the
thread-pool only replenishes thread that panic
and
scoped_thread-pool needs to wait for all threads in its scope to finish

[LukasKalbertodt]

@Cranc Creating a thread for each request (== query) isn't a great idea. Creating a thread costs some time and this issue addresses the problem that threads are created and killed to often. Having one thread per client is how it's usually done.

I'm afraid the linked crates are not really what we want. Those threadpools are designed for executing expensive functions as fast as possible. So you will usually use them to create a pool with as many workers as CPU cores and it will schedule the tasks accordingly.

A database server is a whole different story. For example: If the pool is full and a new client wants to connect we either have to refuse the connection OR he has to wait until another client disconnects again.

So what I think: Either we implement a threadpool ourself (pretty hard, but could be fairly interesting if you're interested in Rust and threads) or we just don't do anything. Our current solution is not too bad and this issue is really just a "nice-to-have" thing. P-very-low ;)

[Cranc]

@LukasKalbertodt okay i can see that but currently this should not be a big problem we are talking here about maybe 1-10 threads in dev stage, but later on it will probably result in some problems when trying to implement the server for use with larger crowds of people and having/managing maybe up to 200 threads may be a slight problem if you wanna keep the 'static' solution.

I say we can wait with that decision later, i for my part would be interested in making our own thread-pool but currently i got enough to do in storage group