-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 12-01-31 03:42 PM, Nick Mathewson wrote:
On Tue, Jan 31, 2012 at 2:46 PM, David Goulet dgoulet@ev0ke.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi everyone,
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/Multithreaded...) 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.
I do agree on that! However, sometimes APIs from those kind of libs can be quite complex (if I think about the red-black tree in URCU...) so having compat layer between lock and lockless is sometime a bit of work.
So going for a wait-free queue and a normal locked queue, it's not that difficult (in terms of APIs/ABIs handling) but the question I think is do we want first to do a "normal locking queue" in the tor code tree and than go for a lockless from a external lib with a compat layer between lock and lockless ?
Personally, I think we should go straight for one type of data structure and make sure we create a decent compat layer on top to be able to switch from one technology to an other easily.
Does it makes sense to you?
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.)
Well, I'm not too knowledgeable in crypto implementation but if some hardware can be use to do the job, it will considerably speed up the process so a situation where your crypto will go faster than queuing events is a possibility (if I understand the question right).
Cheers! David
cheers,