<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>The decorators would abstract the logic of spawning a process or thread and maintaining its lifecycle.<br><br></div><div>I think it could be a good fit for the `concurrent.futures` module. <br>Decorated functions would return a `Future` object and run the logic in a separate thread or process.<br></div><div><br><br></div>@concurrent.futures.thread<br></div>def function(arg, kwarg=0):<br></div>    return arg + kwarg<br><br></div>future = function(1, kwarg=2)<br></div>future.result()<br><br><br></div>The Process decorator in particular would support use cases such as running unstable code within an application taking advantage of process separation benefits.<br>I often found myself relying on external APIs which would either crash or run indefinitely affecting my application stability and performance.<br></div><br><br></div>@concurrent.futures.process(timeout=60):<br></div>def unstable_function(arg, kwarg=0):<br></div>    # hang or segfault  here<br></div>    return arg + kwarg<br><br></div>future = unstable_function(1, kwarg=2)<br></div>try:<br></div>    future.result()<br></div>except TimeoutError as error:<br></div>    print("Function took more than %d seconds" % error.args[1])<br></div>except ProcessExpired as error:<br></div>    print("Process exit code %d" % error.exitcode)<br><br></div><div>In case of timeout, the process would be terminated reclaiming back its resources.<br></div><div><br><br></div>Few years ago I wrote a library for this purpose which turned out pretty handy in reducing the boilerplate code when dealing with threads and processes. It could be a starting point for discussing about the implementation.<br><a href="https://pypi.python.org/pypi/Pebble">https://pypi.python.org/pypi/Pebble</a><br><br></div></div>