Pursuant to advice given in my first and only post here:
https://bitcointalk.org/index.php?topic=64708.0 (thanks everybody), I indeed used rpc (through http) to control the bitcoin client and everything seems to be working fine.
Question: Currently the program I developed to control the bitcoin client is single-threaded, but eventually it will be multithreaded. In other words, there will be multiple threads (possibly many) all acting as independent agents and customers of bitcoin, and they will all be attempting to access and control the bitcoin client simultaneously via the rpc api. My question is whether the bitcoin client is set up for this kind of use case or not.
For instance, will it simply queue up waiting http connections and block them while it serves them one at a time? If so, that's completely fine and acceptable. I just have nightmarish visions of the bitcoin client's output being scrambled over the various connections, one thread getting the return values that another thread is supposed to get, etc.
Thanks for any insights.
