[tor-dev] Torsocks reengineered

[David Goulet]

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 at riseup.net
> http: http://warms0x.github.com
> 
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130614/c74d48c5/attachment.pgp>