importing wallet blocks gui thread about clams

[creativecuriosity]

Going through and cleaning up the issue tracker.

Not sure I understand, tryphe.
Explanation?
Progress?
:)

[tryphe]

RPCExecutor (I think that's the name) should run within its own context, but still blocks the calling thread, in turn making things cumbersome instead of speeding them up. It's a fundamental oversight with bitcoin-qt to just make multiple contexts that wait on each other. What we want is an execution tree, while the current implementation reduces us to a single point of execution at most of any given time.

We need mutexes for specific things and not just one mutex for the entire DB. This is why fixes like #183 work without consequence (hopefully). Unfortunately this involves determining which resources are needed for certain blocks of code and making custom mutexes for each of those relevant blocks of code. In other words, a lot of work. Probably too much work for anyone who didn't design this implementation in the first place.

A better design would be a set of signals from a DB container, with its own thread context, to the GUI, that way the GUI won't need to block for any reason. In other words, we want the GUI to be given data by the DB when it's finished doing its own thing, not force the GUI to wait to read the DB. You would still need block specific mutex locks like I mentioned above but I feel like they would be easier to deal with inside a relevant DB container than from the GUI.

I don't really feel like this is worth doing without more with the GUI, but at the same time I feel like the current design holds us back from doing anything useful with the GUI because it's very heavy to add anything.

[creativecuriosity]

Thanks for the explanation, tryphe :)

Going to close this then - can I get you to create a new issue outlining the design ideas/decisions for such an over-arching GUI update.

Something that can get reviewed and discussed by dooglus, xploited, etc.?

[tryphe]

Thanks - I feel like this is something that eventually needs to be done, but I have no experience with levelDB. Without some major guidance I feel like I'd be running backwards trying to introduce parallelism on something I don't understand.

Most modern DB libraries can support parallelism in some way. Maybe there is a way around this by using something like https://github.com/rescrv/HyperLevelDB? This might avoid our nightmare scenario of having to revamp a bunch of mutexes to be as fast as possible for their individual read/write scenarios. I'm just not sure if it will add too much complexity or help us in ways that we need. I'm a database newb =p