Related: https://community.esri.com/t5/arcgis-api-for-python-questions/is-there-an-example-for-how-to-use-the...
I went into the source code to try and figure out how setting "future=True" behaved in various methods for arcgis.features.FeatureLayer objects, such as delete_features() or edit_features(). Here's a snippet from the end of delete_features(), found in ~env\Lib\site-packages\arcgis\features\layer.py:
if future is False:
return self._con.post(path=delete_url, postdata=params)
else:
params["async"] = True
import concurrent.futures
executor = concurrent.futures.ThreadPoolExecutor(1)
res = self._con.post(path=delete_url, postdata=params)
time.sleep(2)
future = executor.submit(
self._status_via_url,
*(self._con, res["statusUrl"], {"f": "json"}),
)
executor.shutdown(False)
return future
Somebody please correct me if I'm wrong, but isn't this implementation of a concurrent.futures.ThreadPoolExecutor pointless? Whether it's edit_features() or delete_features() or whatever, they're all only sending a single http POST request at the end of the day, and they all create only a single thread. As I understand it, the ThreadPoolExecutor will block the rest of the program until all its threads (well, just one here) finish and join back together. I'm also not sure the motivation behind the 2 second sleep.
Am I misunderstanding something? It seems like maybe they should instead be returning us all the stuff they pass to executor.submit() so that we can put together our own thread pool and send a bunch of requests at once.
