Author serhiy.storchaka
Recipients brett.cannon, dino.viehland, ned.deily, serhiy.storchaka, yselivanov
Date 2017-06-09.05:40:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1496986831.58.0.841763387092.issue30604@psf.upfronthosting.co.za>
In-reply-to
Content
User code shouldn't allocate PyInterpreterState and PyThreadState structures, it only uses structures created by the interpreter. Changing the size of PyInterpreterState should be safe. The only possible breaking compatibility is if user code directly access co_extra_user_count, co_extra_freefuncs, async_gen_firstiter or async_gen_finalizer rather than using the API: _PyEval_RequestCodeExtraIndex(), _PyCode_GetExtra(), _PyCode_SetExtra(), _PyEval_GetAsyncGenFirstiter(), _PyEval_SetAsyncGenFirstiter(), _PyEval_GetAsyncGenFinalizer() and _PyEval_SetAsyncGenFinalizer().

Nick's idea about _preserve_36_ABI_1 and _preserve_36_ABI_2 should   address concerns about direct access to async_gen_firstiter and async_gen_finalizer. Direct access to co_extra_user_count and co_extra_freefuncs obviously can't be preserved.

PyInterpreterState and PyThreadState are not in the stable ABI. They are opaque types when use limited API. May be they should be made opaque for all user code (in 3.7+).
History
Date User Action Args
2017-06-09 05:40:31serhiy.storchakasetrecipients: + serhiy.storchaka, brett.cannon, ned.deily, dino.viehland, yselivanov
2017-06-09 05:40:31serhiy.storchakasetmessageid: <1496986831.58.0.841763387092.issue30604@psf.upfronthosting.co.za>
2017-06-09 05:40:31serhiy.storchakalinkissue30604 messages
2017-06-09 05:40:31serhiy.storchakacreate