summaryrefslogtreecommitdiff
path: root/80/2703f8feaf7bc81de99aaaeb61e9f6232cdc2d
blob: 9baea6fff591cd6bf1fa829961d16a301291cdbe (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
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 <grarpamp@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAD2Ti2-wqMwxJ6iU-z2kYjUjc4GkYMo0dWjL4rcPr2DjODfirQ@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.