|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 27, 2011, 02:37:35 AM |
|
Cute, but definitely not that easy. If it was, we would have already done that by now. There are way too many "there is only one RPC thread" assumptions built into the code at the present time.
|
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 27, 2011, 03:52:04 AM |
|
What if the connection threads grabbed a lock, and the "real" multithreading only occurs when the RPC function itself releases that lock?
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 27, 2011, 05:40:48 AM |
|
It's such a mess that I thought about ripping out boost SSL, and doing threading with straight OpenSSL C API. That eliminates a few of the assumptions, but not all by a long shot.
If you really do manage to fix them all, your pull request will get merged faster than you can say "tonal"
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 27, 2011, 03:53:48 PM |
|
Well, locking helped the non-SSL code. I can no longer crash it. Not sure I care enough to figure out the SSL problem.
|
|
|
|
jordanlewis
Newbie
Offline
Activity: 5
Merit: 0
|
|
April 29, 2011, 06:27:06 PM |
|
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.
|
|
|
|
jordanlewis
Newbie
Offline
Activity: 5
Merit: 0
|
|
April 29, 2011, 06:34:43 PM |
|
I forgot to mention that the code already uses Boost/ASIO enough that making the RPC server code asynchronous is a pretty natural direction to go in.
|
|
|
|
Luke-Jr (OP)
Legendary
Offline
Activity: 2576
Merit: 1186
|
|
April 29, 2011, 11:40:44 PM |
|
Asynchronous wouldn't solve it for me. I have JSON-RPC requests blocking on loopback JSON-RPC requests. My current code is working so long as I build without SSL support, so I guess it's good enough for now.
|
|
|
|
xf2_org
Member
Offline
Activity: 98
Merit: 13
|
|
April 30, 2011, 12:26:55 AM |
|
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.
Definitely! We would love to see a patch that updated the RPC HTTP server to use async I/O.
|
|
|
|
|