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
129
130
131
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pieter.wuille@gmail.com>) id 1Rt6ru-00046A-1a
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Feb 2012 00:19:10 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.41 as permitted sender)
client-ip=74.125.82.41; envelope-from=pieter.wuille@gmail.com;
helo=mail-ww0-f41.google.com;
Received: from mail-ww0-f41.google.com ([74.125.82.41])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Rt6rt-00054a-AA
for bitcoin-development@lists.sourceforge.net;
Fri, 03 Feb 2012 00:19:09 +0000
Received: by wgbdt11 with SMTP id dt11so588672wgb.4
for <bitcoin-development@lists.sourceforge.net>;
Thu, 02 Feb 2012 16:19:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.180.96.230 with SMTP id dv6mr8006385wib.11.1328228343147; Thu,
02 Feb 2012 16:19:03 -0800 (PST)
Received: by 10.223.68.211 with HTTP; Thu, 2 Feb 2012 16:19:02 -0800 (PST)
Received: by 10.223.68.211 with HTTP; Thu, 2 Feb 2012 16:19:02 -0800 (PST)
In-Reply-To: <4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com>
References: <D55C3D18-8286-44E9-B877-6FCE7C05E980@ceptacle.com>
<CAJna-HiS34V5rNrRfFOMRJ6JhRmS1aeEE3oA=o07Hgf4S6qNfw@mail.gmail.com>
<54950761-EBFB-402E-8D7B-0B54A08260D2@ceptacle.com>
<CAD2Ti29cto8wS1jO5yOkORbE48c+t6Of2vysXcA0xM9LKCOCgg@mail.gmail.com>
<4CE9708D-0627-480C-B928-3F812544CD90@ceptacle.com>
Date: Fri, 3 Feb 2012 01:19:02 +0100
Message-ID: <CAPg+sBg16OPdyi3MQ+sfBR+z_ArP6c8KpU36pDA0MEdXpk9fxQ@mail.gmail.com>
From: Pieter Wuille <pieter.wuille@gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: multipart/alternative; boundary=f46d0437491792ea9004b804426a
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
(pieter.wuille[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: 1Rt6rt-00054a-AA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Announcement: libcoin
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, 03 Feb 2012 00:19:10 -0000
--f46d0437491792ea9004b804426a
Content-Type: text/plain; charset=ISO-8859-1
> You will also find the RPC server in libcoin blistering fast compared to
the Satoshi client. (It was actually what got me to write libcoin in the
first place...). The Satoshi client HTTP server executes all rpc commands
in its own thread, but to do so, it needs to stop the thread of the Node,
even though the command executed is just a query (i.e. not a SendTo), you
hence have two threads blocking each other and when they wait, you wait...
In libcoin all the query methods access the blockChain as a const object
and they can hence safely query it without intervening the work of the Node
thread. The exception are the SendTo methods that first query if a
transaction can take place, then pushes it to the work-queue of the Node
thread and again exits immediately. The actual execution then follows once
the Node has finished its current tasks (e.g. validating a block).
Hello Michael,
I'm impressed by your refactorings, and hope some of them can make it into
the Satoshi codebase. I am however not sure what you've said above is safe.
In particular, how do you guarantee that no other thread modifies the
blockchain structure while you are performing your query on it? Does the
query code operate on a const copy of the structure, or is there guaranteed
only one thread accessing it?
I've been thinking about moving to read-write locks that allow multiple
threads reading the datastructure simultaneously, but removing the locking
all together sounds wrong to me.
--
Pieter
--f46d0437491792ea9004b804426a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<p>> You will also find the RPC server in libcoin blistering fast compar=
ed to the Satoshi client. (It was actually what got me to write libcoin in =
the first place...). The Satoshi client HTTP server executes all rpc comman=
ds in its own thread, but to do so, it needs to stop the thread of the Node=
, even though the command executed is just a query (i.e. not a SendTo), you=
hence have two threads blocking each other and when they wait, you wait...=
In libcoin all the query methods access the blockChain as a const object a=
nd they can hence safely query it without intervening the work of the Node =
thread. The exception are the SendTo methods that first query if a transact=
ion can take place, then pushes it to the work-queue of the Node thread and=
again exits immediately. The actual execution then follows once the Node h=
as finished its current tasks (e.g. validating a block).</p>
<p>Hello Michael,</p>
<p>I'm impressed by your refactorings, and hope some of them can make i=
t into the Satoshi codebase. I am however not sure what you've said abo=
ve is safe. In particular, how do you guarantee that no other thread modifi=
es the blockchain structure while you are performing your query on it? Does=
the query code operate on a const copy of the structure, or is there guara=
nteed only one thread accessing it?</p>
<p>I've been thinking about moving to read-write locks that allow multi=
ple threads reading the datastructure simultaneously, but removing the lock=
ing all together sounds wrong to me.</p>
<p>-- <br>
Pieter<br>
</p>
--f46d0437491792ea9004b804426a--
|
