It's cool that the Foreground thread option has been added to the tool options since it does seem to run basic operations a bit faster, but I've come across a nasty bug that seems to be intermittent and latent. Primarily when edits are performed in a loop, it seems that the Foreground thread will disregard, or fail to properly manage a da.Editor context:
import arcpy
for fc2 in ['a', 'b', 'c']:
with arcpy.da.Editor('fc'):
with arcpy.da.InsertCursor('fc', '*') as cur:
for row in arcpy.da.SearchCursor(fc2, '*'):
cur.insertRow(row)
Here's a simple toy example where a loop is occurring and an edit session is being created on each loop. In my actual code, this is necessary since there are multiple operations occurring that need an edit session (I will share if anyone is interested, but it uses some wrapper code that makes it non-standard arcpy, at the base level this is all that's happening).
When this is run on a GP thread, it all works perfectly. However, the Foreground thread seems to create some sort of race condition that nullifies the edit session, or tries to create the second edit session before the first is removed. This is also not consistent, since the tool gets to a different random point and either throws a 'Cannot update features outside edit session' error or a 'Cannot get exclusive schema lock' error which means even within the bug there's something else going on.
This is kinda a warning more than anything since there's no way to detect which thread your python tool is running on right now, but I figured it would still be good to post here.
