Re: [tor-dev] Torsocks reengineered

["warms0x" <warms0x@xxxxxxxxxx>]

(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: warms0x@xxxxxxxxxx
http: http://warms0x.github.com

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev