Higher performance is always cool.

However sometimes even that doesn't deliver - a high-bandwidth low-IO
VPS, a server with a performance bump etc. - there's always a
circumstance that could fry IO performance transitorily, and in those
cases, you want libbitcoin to remain rock solid.

Is this the case now?

(It sounded a bit like lb catches fire if there's an IO lag this is why
I asked these things - if so that would be terrible as it'd be a kind of
a ticking bomb logic about it)

On 2014-01-06 11:32, Amir Taaki wrote:

> If the underlying throughput is limited and you want to write more data
> than the disk can handle, the only solution is to write less data /
> index less keys. And that's more of a workaround which is why I've been
> working on more performant blockchain databases:
> https://wiki.unsystem.net/index.php/Libbitcoin/Blockchain [1]On 05/01/14 20:38, William Swanson wrote:
> On Sat, Jan 4, 2014 at 11:55 AM, mlmikael <mlmikael@???> wrote: Can't write requests block internally somehow in such a way that writes always succeed unless there's a physical error about the storage medium? An obvious way to do it would be to limit the number of outstanding network block requests to the number of free slots in the queue. That way, you will never overflow, and will throttle back gracefully as things fill up. -William

_______________________________________________
Libbitcoin mailing list
Libbitcoin@???
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin [2]



Links:
------
[1] https://wiki.unsystem.net/index.php/Libbitcoin/Blockchain
[2] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/libbitcoin