(snip!) >> 4) 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? 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: warm...@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