-----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 <[email protected]> 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/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.
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, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJPKJo3AAoJEELoaioR9I02Yt8IAJXv4pgj53jhAtqlMX4DfmpX SCu/Vnx3+JUFsS1VgJkXXcA1f4pQNNJasoTHcjXDU7eJD2LD/sWkfbM9FrW1vwgd WjpNwRk0WFFQDZFHULjg72iftEVbLEJNjDhsvX0U/YHwHqgm+OVvoUHEwe22kON1 4peqyGyrem8lutaKA9+SLXhEC7U44Tn7tUqCUj9rWZAtAcCH0AE8baNPiHShNWYx Av+ddnrCt3Pcpo3KZzVK5ZU7D4Ub7/rolyH4T5FjMm0ukmNv+gAjxfDQpqhzFA0h Go92OHHno8kB74hsmMDIVCljUbRMbBn/vOMWPpWmvEiYJD6ofC9neV1qnbjhT7s= =lagt -----END PGP SIGNATURE----- _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
