As I understand it, it's not actually all that beneficial to spin off a new request thread for every incoming connection, at least in standard webservers. The general approach is to have a few worker threads processing requests, but each of them asynchronously. So one thread would be able to handle a few incoming connections at once by removing the sequential connection processing code.
I've had a look at the RPC server code and it doesn't seem like it would be that hard to get basic asynchronous IO going, which would help solve any timeout issues by itself. Of course you'd still need to put a lock around all of the actual bitcoin calls until that "one rpc thread" assumption is removed, but nonetheless I think it would be an improvement.
Does that sound like it could be a helpful patch? I'd like to get some feedback before doing any more work in this direction.
I've had a look at the RPC server code and it doesn't seem like it would be that hard to get basic asynchronous IO going, which would help solve any timeout issues by itself. Of course you'd still need to put a lock around all of the actual bitcoin calls until that "one rpc thread" assumption is removed, but nonetheless I think it would be an improvement.
Does that sound like it could be a helpful patch? I'd like to get some feedback before doing any more work in this direction.
Definitely! We would love to see a patch that updated the RPC HTTP server to use async I/O.
