search

pedrorrivero / qrand

A multiprotocol and multiplatform quantum random number generation framework
https://pypi.org/project/qrand/
Apache License 2.0
23 stars 14 forks source link

Cache persistence #6

Open pedrorrivero opened 3 years ago

pedrorrivero commented 3 years ago

Is your feature request related to a problem? Please describe.

Cache is hold in memory and gets erased when the python job holding it finishes.

Describe the solution you'd like

It should be possible to choose between holding the cache in memory or storage.

Describe alternatives you've considered

It is currently possible for the user to save and load the cache manually. However, if two programs are running at the same time and one uses bits in the cache, this will not be reflected on the other one. Leading to possible security issues and statistical biases.

Additional context

Concurrent access to the local file holding the cache has to be handled. This suggests using a singleton pattern along with semaphores in order to make it thread-safe. Performance has to be taken into account, since accessing a local file is always slower than simply reading from memory. Also, this feature should be available for all major OS distributions (i.e. Windows, MacOS, and Linux/Unix).

jaimebw commented 3 years ago

Hey Pedro! I was looking through this issue( and even though I don't really know anything about Quantum computing ) I think that what you might be looking for is the functools library . More precisely, the "cache" decorator but you've got many options for this. Hope this may be useful!

pedrorrivero commented 3 years ago

Thanks @jaimebw! I will take a look at it, although in my understanding that decorator is used to reduce the times you repeat a given calculation by storing its result. In this case we want to do something else: get different results from the same call by retrieving the random bits from some persistent source (e.g. a system file).

Am I getting it wrong?

jaimebw commented 3 years ago

Hey Pedro, I've thinking that you might use a lock thread while running the program. But, tbh, I don't really know how to tackle this issue 😅. The GIL is quite an issue while trying to access multiple threads at the same time and using multiple cores is the recommended approach. Maybe you could try using an async funtions and hope that the "randomness" of the execution whilst using a system file or a global var may let you get your desired output. Good luck with the implementation!