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
But public key operations are still written in Pike, right? Then if any THREADS_ALLOW should be added, that's in the Gmp module.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-02-13 08:28: Subject: Re: THREADS_ALLOW
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
/ Brevbäraren
Yes they are. Both RSA and DSA now uses accessor functions, so it should be possible to replace them with a glue against nettle at any time. At least for someone who knows how to convert between Pike Gmp objects and mpz-structs.
/ Martin Nilsson (saturator)
Previous text:
2004-02-13 08:30: Subject: Re: THREADS_ALLOW
But public key operations are still written in Pike, right? Then if any THREADS_ALLOW should be added, that's in the Gmp module.
/ Niels Möller (vässar rödpennan)
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:
2004-02-13 07:48: Subject: THREADS_ALLOW
Would it be a good idea to add some THREDS_ALLOW/THREADS_DISALLOW in the crypto glue for encryption and hashes?
/ Martin Nilsson (saturator)
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:
2004-02-13 08:29: Subject: THREADS_ALLOW
Yes? Why not?
/ Mirar
If THREADS_ALLOW is there for every operation on an mpz object, it seems like it should be there for any crypto operation that might take time as well...
Isn't THREADS_ALLOW (almost) a noop when there is just one thread running, anyway?
/ Mirar
Previous text:
2004-02-13 09:37: Subject: THREADS_ALLOW
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)
pike-devel@lists.lysator.liu.se
-
Alexander Demenshin -
Martin Nilsson (saturator) ＠ Pike (-) developers forum -
Mirar ＠ Pike developers forum
-
Niels M�ller (v�ssar r�dpennan) ＠ Pike (-) developers forum