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
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1Sfn3p-00071j-Kq
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 07:04:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.47 as permitted sender)
client-ip=209.85.160.47; envelope-from=laanwj@gmail.com;
helo=mail-pb0-f47.google.com;
Received: from mail-pb0-f47.google.com ([209.85.160.47])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
(Exim 4.76) id 1Sfn3o-0004Bg-VY
for bitcoin-development@lists.sourceforge.net;
Sat, 16 Jun 2012 07:04:41 +0000
Received: by pbbrq2 with SMTP id rq2so5789857pbb.34
for <bitcoin-development@lists.sourceforge.net>;
Sat, 16 Jun 2012 00:04:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.240.99 with SMTP id vz3mr28394350pbc.60.1339830274908; Sat,
16 Jun 2012 00:04:34 -0700 (PDT)
Received: by 10.143.44.2 with HTTP; Sat, 16 Jun 2012 00:04:34 -0700 (PDT)
In-Reply-To: <CAD2Ti2-wqMwxJ6iU-z2kYjUjc4GkYMo0dWjL4rcPr2DjODfirQ@mail.gmail.com>
References: <CAD2Ti2-wqMwxJ6iU-z2kYjUjc4GkYMo0dWjL4rcPr2DjODfirQ@mail.gmail.com>
Date: Sat, 16 Jun 2012 09:04:34 +0200
Message-ID: <CA+s+GJBqjvSkJp3dv_ZoeBh4QqF7z483PpCkCqsDZfQYGcJ65Q@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: grarpamp <grarpamp@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b3396ad9860e204c2918ba0
X-Spam-Score: -0.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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1Sfn3o-0004Bg-VY
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [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: Sat, 16 Jun 2012 07:04:41 -0000
--047d7b3396ad9860e204c2918ba0
Content-Type: text/plain; charset=UTF-8
On Fri, Jun 15, 2012 at 10:55 PM, grarpamp <grarpamp@gmail.com> wrote:
> 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?
>
This has nothing to do with priority and "user interrupts", but with the
locks on the wallet and client. Every RPC command takes both locks, and
releases them only when finished.
Shutting down also requires both locks, so the operations will be
serialized.
This protects the database and critical data structures. Sure, there might
be some cases in which the locks are not necessary, or read/write locks
could be used instead to improve concurrency, but this has to be approached
really carefully.
Wladimir
--047d7b3396ad9860e204c2918ba0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div><br></div><div><br><div class=3D"gmail_quote">On Fri, Jun 15, 2012 at =
10:55 PM, grarpamp <span dir=3D"ltr"><<a href=3D"mailto:grarpamp@gmail.c=
om" target=3D"_blank">grarpamp@gmail.com</a>></span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
While happily processing these:<br>
received block ...<br>
SetBestChain: new best=3D... =C2=A0height=3D... =C2=A0work=3D...<br>
ProcessBlock: ACCEPTED<br>
<br>
bitcoind very often refuses to answer rpc queries such as getinfo/stop,<br>
or signals such as kill/ctrl-c. It even registers:<br>
=C2=A0ThreadRPCServer method=3Dgetinfo/stop<br>
in the debug log. But the action doesn't happen as expected.<br>
<br>
Shouldn't it be checking and processing all user interrupts like<br>
once per block and doing the chain in the background?<br></blockquote><div>=
<br></div><br class=3D"Apple-interchange-newline">This has nothing to do wi=
th priority and "user interrupts", but with the locks on the wall=
et and client. Every RPC command takes both locks, and releases them only w=
hen finished.<div>
<br></div><div>Shutting down also requires both locks, so the operations wi=
ll be serialized.</div><div><br></div><div>This protects the database and c=
ritical data structures. Sure, there might be some cases in which the locks=
are not necessary, or read/write locks could be used instead to improve co=
ncurrency, but this has to be approached really carefully.<br>
<br></div><div>Wladimir</div><div><br></div></div></div>
--047d7b3396ad9860e204c2918ba0--
|
