Hello! Comments below.
warms0x:
(snip!)
- One of the biggest technical issues is that it's not thread safe and
fixing it right now would add an important impact on performance adding locks to multiple global data structures. A clean rewrite would allow to take into account this *very* important feature from the start without any ugly hacks in the current code base.
Please be extra careful with locking, especially since you're going to redesign this.
I haven't personally reviewed torsock's current data structure use, but in general, when somebody looks at a codebase and says "this code is not threadsafe - it needs more locking around its data structure use", that person is usually wrong, or at best only half right. It's almost always better to get the locking out of your critical path and use thread local storage, message passing, and/or job scheduling instead of direct lock acquisition+release for commonly used data structures.
Since everybody is piling on advice I might as well throw in some of my own, bear in mind I don't claim to fully understand the extent of what torsocks is capable of.
Doesn't it's behavior/functionality map well to a libev/libevent loop instead of a multi-threaded model?
You can see Torsocks as an "inprocess" library that is loaded using LD_PRELOAD and hijacks a good amount of symbols of the Libc to make sure any communications goes through the Tor network.
Now, this means that Torsocks is quite dependent on the application threading model which means that loading into an application that uses a lot of threads brings the possibility for anything *in* Torsocks to be concurrent.
Using a "big fat lock" would solve the issue but the performance hit would be quite important and it's undesirable.
I sent some days ago the locking design to handle such a thing. Maybe you could have a look at it if you are interested? :)
Cheers! David
It does mean you likely need to approach the problem from a slightly different angle, but with the I/O calls that are being made, it would provide a good high performance alternative without a lot of concurrency overhead.
I highly recommend reading some of the redis project's source code (https://github.com/antirez/redis), which also relies on libev and is quite readable (as far as C goes).
- warms0x
xmpp: warms0x@riseup.net http: http://warms0x.github.com
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev