On Sat, Apr 13, 2013 at 10:42 AM, wac waldoalvarez00@yahoo.com wrote:
untill you post the code.
I thought Tor already had some level of locking since multiple applications can connect to it at the same time via SOCKS. I completely agree about replacing the macros though.
On Mon, Apr 15, 2013 at 1:37 AM, Navin Francis navin.kurupacheril@gmail.com wrote:
Tor isn't multithreaded like that. Its main thread uses an asynchonous event loop. Other threads are used for cryptography-related tasks. Most of the data structures aren't locked, because they don't need to be shared between threads. Only the ones that need to get used for inter-thread communication are locked.
Personally, if I were going to try to make an in-process C API for Tor, I'd make a command queue structure that any thread could use to asynchronously send commands to the main thread, so that the only change you'd need to make in the main thread would be enough locking to handle queued commands and to queue replies. That way the codebase changes would be much simpler.
In fact, that's how the controller interface works.
peace,
On Mon, Apr 15, 2013 at 8:01 AM, Nick Mathewson nickm@alum.mit.edu wrote:
Tor isn't multithreaded like that. Its main thread uses an asynchonous event loop.
Ah, I see.
I'd make a command queue structure that any thread could use to
I was actually thinking along the same lines but I thought that tor also has a command queue for SOCKS connections so the library could just add data to Tor's queue.
Regards, Navin
-
Navin Francis -
Nick Mathewson