add code to lazily precompute multiplication tables

[oberstet]

this is an attempt to fix #180

the does not change any existing behavior, but adds new behavior:

when PYTHON_ECDSA_ENABLE_LAZY_PRECOMPUTE env var is set, the multiplication tables for curves are only precomputed upon first use.

without the env var being set (the current behavior), tables for all supported curves are precomputed at import time regardless of whether the curves are used in the user app at all.

effect can be seen in this test:

(cpy382_2) oberstet@intel-nuci7:~/scm/3rdparty/python-ecdsa$ python test.py 
python-ecdsa v0.16.0+1.g3388afc
0.4552568449998944
(cpy382_2) oberstet@intel-nuci7:~/scm/3rdparty/python-ecdsa$ PYTHON_ECDSA_ENABLE_LAZY_PRECOMPUTE=1 python test.py 
python-ecdsa v0.16.0+1.g3388afc
0.020854599999438506
(cpy382_2) oberstet@intel-nuci7:~/scm/3rdparty/python-ecdsa$ 

using test.py:

import timeit

def test1():
    from ecdsa.curves import SECP256k1

print(timeit.timeit(test1, number=1))

[coveralls]

Coverage decreased (-0.02%) to 97.996% when pulling e0e6c38 on oberstet:lazy-precompute-jacobi into f27b20f on warner:master.

[tomato42]

The CI also failed: https://travis-ci.org/github/warner/python-ecdsa/builds/742220130

[oberstet]

ok, pushed adjustments based on your feedback, and tested on cpy and pypy:

• https://gist.github.com/oberstet/905251d53a5168ea8c56996618a3a4cb
• https://gist.github.com/oberstet/c8ed75f1be47f2eacbfccc9b25d5565d

2 notes:

• in the original code, the precomputation was called with constructor x/y whereas in the new code, x/y can be a gmp wrapped x/y. I tested both the non-gmp and gmp tox envs, so that should be good?
• I now added a writer (single I guess) lock within the precompute block. new locks, means new risks for deadlock. also that lock will now happen later on .. lazy (which is the whole point).

[tomato42]

ok, pushed adjustments based on your feedback, and tested on cpy and pypy:

* https://gist.github.com/oberstet/905251d53a5168ea8c56996618a3a4cb

* https://gist.github.com/oberstet/c8ed75f1be47f2eacbfccc9b25d5565d

2 notes:

* in the original code, the precomputation was called with constructor x/y whereas in the new code, x/y can be a gmp wrapped x/y. I tested both the non-gmp and gmp tox envs, so that should be good?

check the CI results: https://travis-ci.org/github/warner/python-ecdsa/pull_requests

* I now added a writer (single I guess) lock within the precompute block. new locks, means new risks for deadlock. also that lock will now happen later on .. lazy (which is the whole point).

the solution to deadlocking is not locking in fewer places but to lock in correct places; here we need to acquire reader lock when checking if the precompute is initialised, free it, and then acquire a writer lock if it wasn't initialised; then after getting the writer lock we need to check again for initialisation

[oberstet]

here we need to acquire reader lock when checking if the precompute is initialised, free it, and then acquire a writer lock if it wasn't initialised; then after getting the writer lock we need to check again for initialisation

I've updated the PR which should reflect ^ now ..

[tomato42]

unused import

[tomato42]

it's _scale_lock because it was used for scale() but now we also use it for precompute... maybe change its name to _update_lock?

[tomato42]

also few previous versions failed in CI because of excessive line length, you may want to run tox -e codechecks before pushing a new version

[oberstet]

thanks for your time and for reviewing! pls merge.

sidenote: the CI settings on travis for this repo don't allow for unbuilt pushes to the PR supersede others (to CI run requests pile up), and for whatever reasons, a single CI run takes hours.

[tomato42]

the builds take hours because travis limited the number of free workers recently: https://www.traviscistatus.com/#month don't know why exactly, unfortunately I don't have access to administer it to fix the dismissal of stale PRs or lack of CI status in PRs either... I'll send an email to Warner tomorrow

[tomato42]

ok, looks good, but I'll wait until the CI finishes before merging

[oberstet]

thanks for approving!

re: travis: ah, right. interesting - news for me. guess we'll run into this soonish as well on our oss stuff ..

[tomato42]

merged, thank you!