You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
from threading import Thread
def mine():
.... mine() content....
...... some code here...
@app.route.....
def request_for_mine():
.... some code here....
# Launch the thread for the mine process, so that the API will be still available
Thread(target = mine).start()
return response
The text was updated successfully, but these errors were encountered:
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:
The text was updated successfully, but these errors were encountered: