(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?
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