Open Sanix-Darker opened 5 years ago
Nice idea to perform the execution on different threads. But some API responses are dependent on the entire execution (for example, /chain
endpoint), so they can't be dealt this way.
Also, expected behavior for a client is to call /mine
, and then get the chain, which again can't be dealt on different threads (the chain won't be updated until mine is finished).
Edit: But yes, the mining figuring out the nonce process can be run parallely using multiprocessing module which can take advantage of multiple CPU cores.
A nice approach for handling operations as mining will be the use of RabbitMQ or event data driven architectures. Of course is a big enhacement, but definetly will be necessary in a real time implementation.
When a mining started, it can take too long depending on how the difficulty have been configured, so when that operation start the api is waiting the process end before return a response, it's same when trying to access the api with any other endpoint /chain,... etc, so i suggest to use threads as i do: