What might a tiny-http server using a thread-pool for workers look like?

[GregDavidson]

Does anyone have an example of a simple complete tiny-http server using a thread-pool of workers where the thread-pool is managed by tiny-http? Have I missed such? I only see an example with a fixed vector of 4 threads managed by fn main(). I've also not seen the API for using a thread-pool in the documentation.

I'd be happy to help refine such an example and such documentation and I need something to start with. I'm new to Rust and slogging through the tiny-http source files trying to figure these things out. It's difficult to tell from the implementation what is supposed to be the API and what is temporary scaffolding.

Thanks, _Greg

[tomaka]

For the moment the way tiny-http works is this:

• When you create the Server, tiny-http spawns a background thread dedicated to the listening socket.
• tiny-http manages its internal threads pool. When a client connects, its socket is dispatched to the pool.
• When one of the threads receives an HTTP request, it adds it to a queue, then immediately attempts to read the next HTTP request.
• Calling server.recv() or try_recv() peeks or wait from this queue.

This may seem inefficient, however:

• I think that callbacks are an anti-pattern in Rust and I explicitely avoided them when designing the API. If the background threads had to dispatch to handlers, you would have to use callbacks.
• It permits requests pipelining.
• When non-blocking I/O lands, it will be possible to modify the implementation so that calling recv or try_recv selects from the sockets. This would remove background threads from tiny-http.

[GregDavidson]

Thanks for the clues! I also don't like callbacks. I'm now thinking I misunderstood the function of tiny-http's threads - I thought they were workers which read AND handled requests. It seems that unless I can hijack tiny-http's request-reading threads, I'm going to have to create a second thread pool of request processors (workers) to process the requests read by the request-reading threads. This seems unnecessarily complicated!

The web server I'm writing is a simple thing which simply relays all HTTP Requests to a PostgreSQL database which returns a response as a simple table that is slightly massaged into an HTTP Response. My existing versions in C and in Clojure maintain a pool of worker threads and a pool of database connections. Each thread reads a request, gets a database connection from the database connection pool, sends the request as a string to the database, receives the result and then sends the response to the client. All of these operations are synchronous and require no callbacks.

I see that using a separate thread pool just for reading requests allows for pipelining without complicating the business logic. If and when the major web browsers pipeline their requests by default that could justify the additional complexity and overhead of using a second thread pool of workers doing request processing.

It still seems to me that Rust with tiny-http fits my needs better than the alternatives, so I'm going to keep going!