Hello! Comments below. warms0x: > (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? 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@xxxxxxxxxx > http: http://warms0x.github.com > > _______________________________________________ > tor-dev mailing list > tor-dev@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev