[tor-dev] Parallel Crypto - Library dep.

[Mike Perry]

Thus spake Nick Mathewson (nickm at alum.mit.edu):

> On Tue, Jan 31, 2012 at 2:46 PM, David Goulet <dgoulet at ev0ke.net> wrote:
> > To help the tor project, I'll contribute some of my spare time to improve
> > multithreading for the Tor code base.
> >
> > I've speak a bit with Nick M. and it seems the crypto lib is an important part
> > to begin with. The wiki page
> > (https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto)
> > indicates, basically, that a worker thread pool with a work queue to dispatch
> > crypto events should be the right approach and I do agree.
> >
> > Is it acceptable to link an external library to the project being a dependence?
> 
> It depends, I'd say.  Most of the data structures we're talking about
> here are ones that allow a lockless and locked implementations.  So my
> ideal implementation would be to have the ability to use lockless
> structures where available, but a locked implementation otherwise.
> This would let us work with better lockless libraries if they come
> along, and continue to run on operating systems or on CPUs that don't
> support librcu, and also migrate to another system in the future in
> case a better one comes along.
> 
> But personally, I would be very surprised if this turned out to make a
> very big difference: even symmetric crypto is pretty slow in
> comparison to even the most obvious work-queue implementations, right?
>  (If I'm missing something there, please let me know.)

Linus Tordvalds emerges from 2008 to agree with Nick, and to add:
http://www.realworldtech.com/forums/index.cfm?action=detail&id=91906&threadid=91801&roomid=2

For extra lullz, note the "topic" is "1000 cores SMP is going to
happen". Is this a fake thread, or just some sketch web forum? I can't
find it online anywhere else, and it has a pretty high volume of idiocy,
even for 2008. Other than Linus, of course. My heart goes out to you,
young(er) Torvalds, if that is the real you...

It's also possible that RCU has been through enough trial by fire since
then to have caused Real 2012 Linus to disagree with Fake 2008 Linus.

Either way, it sounds like good sense to make sure we have the option to
say to people "Omg, you hit that crazy crash under heavy crypto load?
Try building with --disable-non-determinism this time."

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120202/cda9e4aa/attachment.pgp>