{"type":"rich","version":"1.0","author_name":"npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","author_url":"https://nostr.ae/npub1tjephawh7fdf6358jufuh5eyxwauzrjqa7qn50pglee4tayc2ntqcjtl6r","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2012-02-02\n📝 Original message:\u003e You will also find the RPC server in libcoin blistering fast compared to\nthe Satoshi client. (It was actually what got me to write libcoin in the\nfirst place...). The Satoshi client HTTP server executes all rpc commands\nin its own thread, but to do so, it needs to stop the thread of the Node,\neven though the command executed is just a query (i.e. not a SendTo), you\nhence have two threads blocking each other and when they wait, you wait...\nIn libcoin all the query methods access the blockChain as a const object\nand they can hence safely query it without intervening the work of the Node\nthread. The exception are the SendTo methods that first query if a\ntransaction can take place, then pushes it to the work-queue of the Node\nthread and again exits immediately. The actual execution then follows once\nthe Node has finished its current tasks (e.g. validating a block).\n\nHello Michael,\n\nI'm impressed by your refactorings, and hope some of them can make it into\nthe Satoshi codebase. I am however not sure what you've said above is safe.\nIn particular, how do you guarantee that no other thread modifies the\nblockchain structure while you are performing your query on it? Does the\nquery code operate on a const copy of the structure, or is there guaranteed\nonly one thread accessing it?\n\nI've been thinking about moving to read-write locks that allow multiple\nthreads reading the datastructure simultaneously, but removing the locking\nall together sounds wrong to me.\n\n-- \nPieter\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120203/270a6572/attachment.html\u003e"}