On Sat, Apr 13, 2013 at 10:42 AM, wac waldoalvarez00@yahoo.com wrote:
Hi Navis:
Good to hear you built it. I have a working library with a defined API but is not re-entrant. It can connect with a server over Tor circuits and transmit/receive data but nothing is re-entrant at all. So the same Tor thread must be used for all of that ATM.
I can fetch webpages like that however and can also do some limited chit-chat over IRC.
I didn't realize that you already had it working :) I guess I will wait
untill you post the code.
I attempted to add some locking to some of the data structures but that is insufficient. For instance lists and buffers. Hash tables are complex. They are defined with some macros in order to make them generic overcoming some limitations of C language but they are less than maintainable IMHO. So I was thinking to replace them with another one already built with a similar license but re-entrant. Found a very good one.
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:
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.
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
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.
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