This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eric.snow
Recipients eric.snow, ncoghlan, serhiy.storchaka, vstinner, yselivanov
Date 2018-05-22.19:34:41
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
In-reply-to
Content
In order to keep subinterpreters properly isolated, objects
from one interpreter should not be used in C-API calls in
another interpreter.  That is relatively straight-forward
except in one case: indicating that the other interpreter
doesn't need the object to exist any more (similar to
PyBuffer_Release() but more general).  I consider the
following solutions to be the most viable.  Both make use
of recounts to protect cross-interpreter usage (with incref
before sharing).

1. manually switch interpreters (new private function)
  a. acquire the GIL
  b. if refcount > 1 then decref and release the GIL
  c. switch
  d. new thread (or re-use dedicated one)
  e. decref
  f. kill thread
  g. switch back
  h. release the GIL
2. change pending call mechanism (see Py_AddPendingCall) to
   per-interpreter instead of global (add "interp" arg to
   signature of new private C-API function)
  a. queue a function that decrefs the object
3. new cross-interpreter-specific private C-API function
  a. queue the object for decref (a la Py_AddPendingCall)
     in owning interpreter

I favor #2, since it is more generally applicable.  #3 would
probably be built on #2 anyway.  #1 is relatively inefficient.
With #2, Py_AddPendingCall() would become a simple wrapper
around the new private function.
History
Date User Action Args
2018-05-22 19:34:41eric.snowsetrecipients: + eric.snow, ncoghlan, vstinner, serhiy.storchaka, yselivanov
2018-05-22 19:34:41eric.snowsetmessageid: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
2018-05-22 19:34:41eric.snowlinkissue33608 messages
2018-05-22 19:34:41eric.snowcreate