On Fri, May 31, 2013 at 8:37 AM, Rune Kjær Svendsen <runesv...@gmail.com> wrote:
> I've thought about this as well. It just seems somewhat clunky to me. I'd
> really prefer having bitcoind put out messages in batches, if it's doable,
> that is.
> I'd run into a lot of concurrency issues, as far as I can see, where I can't
> be sure that the queue isn't written to while, for example, it is opened by
> the program that needs to process the queue items.
> What if a disk operation takes a long time to finish, and a two queue
> operations want to add to the queue simultaneously? This really brings
> forward all the horrors of concurrent programming.

This is not a compelling need to update bitcoind for this.

The vast majority of systems are currently capable of processing a
block, before another block arrives.

As for parallel processing, your "what if" has been a solved problem
for decade(s) now.

Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
Bitcoin-development mailing list

Reply via email to