flask-executor
flask-executor copied to clipboard
Timeout for threads and process
Is there a way to set a timeout for threads or processes? Ideally, it would be something like this:
from flask import Flask
from flask_executor import Executor
app = Flask(__name__)
app.config['EXECUTOR_TIMEOUT'] = 10
executor = Executor(app)
or
@app.route('/run_fib')
def run_fib():
future = executor.submit(fib, 5)
future.set_timeout(10)
return 'OK'
@manolosolalinde what would that behaviour look like? For the most part we're just wrapping the concurrent.futures
API: https://docs.python.org/3/library/concurrent.futures.html
You can already set timeouts on retrieving results from a future
in various ways. Would this instead start a timer at the beginning of the task, and call future.cancel()
if the future
was still in a running state once the timeout was passed?
tl;dr there's no built-in way to do this, though you could wrap this behaviour in a few ways yourself. Do you have an example use case?
Would this instead start a timer at the beginning of the task, and call future.cancel() if the future was still in a running state once the timeout was passed?
Yes, this is exactly the expected behaviour I am looking for.
though you could wrap this behaviour in a few ways yourself
Yes, I know. I was just curious about whether there is an out of the box way to do it. Perhaps it'll make a nice feature request?
Do you have an example use case?
I'm writing an application that triggers a flask endpoint (/add_task_to_queue
)every time a new task document is added to a collection in a database. The flask endpoint function must run every task (a scraper for different websites) in an independent thread. A timeout will be useful to stop threads that are taking too long.
I'm closing this out for now, most use cases would be solved by the existing timeout functionality (even using it at the point of retrieving results would effectively time them out), though I can imagine the use case for "throwaway" tasks whose results are never checked. If you're still keen on this feel free to reopen, but seems wiser to try to follow the existing concurrent.futures
behaviour patterns here