It had its own built in preemptive scheduler and used lots of critical sections (many of them implemented ad-hoc rather than through a consistent API), but since all the target systems were single-core at least no more than one thread at a time would be scheduled. I survived it.


Maybe we're talking past each other. I was talking about usability of bitcoind for a low-volume bitcoin user (at least one tech savvy enough to run a command line tool) as being "not all that bad" in this particular sentence. I wasn't referring to back-end issues and I guess bitcoind in its current state might not scale well enough for a big site to use it unpatched. But really my whole point was about externally visible design features and usability, not about internal design which I can really comment on, never having extensively studied the code and being myself mostly a self taught tinkerer-coder with not all that much of a grip on more abstract software engineering issues.

EDIT: Also, since Bitcoin public keys can be easily derived from the private keys (not the case with RSA such as used in PGP), does it really help all that much to keep them in separate files? Granted, a file with only the public keys in them might be useful for receive-only situations.