Would it be a good idea to add some THREDS_ALLOW/THREADS_DISALLOW in the crypto glue for encryption and hashes?
On Fri, Feb 13, 2004 at 07:50:01AM +0100, Martin Nilsson (saturator) @ Pike (-) developers forum wrote:
Would it be a good idea to add some THREDS_ALLOW/THREADS_DISALLOW in the crypto glue for encryption and hashes?
I guess so. Some operations may take loooong time to execute, especially public/private key operations, and key generation in particular.
/Al
Would make sense in the hash update functions, at least.
For the ciphers, I think the current CBC code will call the ciphers with just one block at a time, so then it's less useful to allow other threads. The cbc code could be optimized for the case that the crypto object inherits CipherState. Then one can use nettle_cbc_encrypt and nettle_cbc_decrypt.
/ Niels Möller (vässar rödpennan)
Previous text:
If I knew that I wouldn't ask, would I. Perhaps the overhead of THREAD_ALLOW is too big to make a positive net result?
Come to think about it you really don't need a fancy locking mechanism. A simple semaphore should do, that ensures that an exception is thrown when two methods are called concurently in a cipher/hash. If that occurs the code is buggy anyway.
/ Martin Nilsson (saturator)
Previous text:
pike-devel@lists.lysator.liu.se