Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfdYb-0007kp-5U for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 20:55:49 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=grarpamp@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SfdYa-0006P4-I9 for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 20:55:49 +0000 Received: by wibhn6 with SMTP id hn6so207667wib.10 for ; Fri, 15 Jun 2012 13:55:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.101.170 with SMTP id fh10mr8282762wib.0.1339793741986; Fri, 15 Jun 2012 13:55:41 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Fri, 15 Jun 2012 13:55:41 -0700 (PDT) Date: Fri, 15 Jun 2012 16:55:41 -0400 Message-ID: From: grarpamp To: bitcoin-development@lists.sourceforge.net Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (grarpamp[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SfdYa-0006P4-I9 Subject: [Bitcoin-development] RPC and signals - processing priority X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 20:55:49 -0000 While happily processing these: received block ... SetBestChain: new best=... height=... work=... ProcessBlock: ACCEPTED bitcoind very often refuses to answer rpc queries such as getinfo/stop, or signals such as kill/ctrl-c. It even registers: ThreadRPCServer method=getinfo/stop in the debug log. But the action doesn't happen as expected. Shouldn't it be checking and processing all user interrupts like once per block and doing the chain in the background? How do busy commerce servers deal with this poor rpc handling? Is there a way to increase the priority of user scheduled tasks? What's going on? Thanks.