[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

Thanks for taking a look Victor!  That info is helpful.  It will likely be a 
few days before I can sort this out.

Once I have addressed the problem I'll re-merge.  I plan on using the 
"buildbot-custom" branch to make sure the buildbots are happy with the change 
before making that PR.

--
stage: patch review -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

> That's okay, Victor.  Thanks for jumping on this.  I'll take a look when I 
> get a chance.

>From what I saw, your first commit was enough to reproduce the crash.

If I recall correctly, Antoine Pitrou modified the GIL so threads exit 
immediately when Py_Finalize() is called. I'm thinking at:

void
PyEval_RestoreThread(PyThreadState *tstate)
{
...
take_gil(tstate);
/* _Py_Finalizing is protected by the GIL */
if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {
drop_gil(tstate);
PyThread_exit_thread();
Py_UNREACHABLE();
}
...
PyThreadState_Swap(tstate);
}

Problem: this code uses tstate, whereas the crash occurred because tstate 
pointed to freed memory:

"""
Thread 1 got the crash

(gdb) p *tstate
$3 = {
  prev = 0xdbdbdbdbdbdbdbdb,
  next = 0xdbdbdbdbdbdbdbdb,
  interp = 0xdbdbdbdbdbdbdbdb,
  ...
}

...

Thread 1 (LWP 100696):
#0  0x00368210 in take_gil (tstate=0x8027e2050) at 
Python/ceval_gil.h:216
#1  0x00368a94 in PyEval_RestoreThread (tstate=0x8027e2050) at 
Python/ceval.c:281
...
"""

https://bugs.python.org/issue36114#msg337090

When this crash occurred, Py_Finalize() already completed in the main thread!

"""
void _Py_NO_RETURN
Py_Exit(int sts)
{
if (Py_FinalizeEx() < 0) {  /* < DONE! */
sts = 120;
}

exit(sts);/* <=== Crash occurred here! */
}
"""

Py_Finalize() is supposed to wait for threads before deleting Python thread 
states:

"""
int
Py_FinalizeEx(void)
{
...

/* The interpreter is still entirely intact at this point, and the
 * exit funcs may be relying on that.  In particular, if some thread
 * or exit func is still waiting to do an import, the import machinery
 * expects Py_IsInitialized() to return true.  So don't say the
 * interpreter is uninitialized until after the exit funcs have run.
 * Note that Threading.py uses an exit func to do a join on all the
 * threads created thru it, so this also protects pending imports in
 * the threads created via Threading.
 */
call_py_exitfuncs(interp);

...

/* Remaining threads (e.g. daemon threads) will automatically exit
   after taking the GIL (in PyEval_RestoreThread()). */
_PyRuntime.finalizing = tstate;
_PyRuntime.initialized = 0;
_PyRuntime.core_initialized = 0;
...

/* Delete current thread. After this, many C API calls become crashy. */
PyThreadState_Swap(NULL);

PyInterpreterState_Delete(interp);

...
}
"""

The real problem for years are *deamon threads* which... BY DESIGN... remain 
alive after Py_Finalize() exit! But as I explained, they must exit as soon at 
they attempt to get GIL.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

That's okay, Victor.  Thanks for jumping on this.  I'll take a look when I get 
a chance.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

For curious people, Pablo Galindo spent a few hours to investigate 
https://bugs.python.org/issue36114 and I spent a few more hours to finish the 
analysis. The bug indirectly crashed my laptop :-)
https://twitter.com/VictorStinner/status/1102528982036201478

That's what I mean by "I don't have the bandwidth": we already spent hours to 
identify the regression ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:


New changeset 4d61e6e3b802399be62a521d6fa785698cb670b5 by Victor Stinner in 
branch 'master':
Revert: bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). 
(GH-11617) (GH-12159)
https://github.com/python/cpython/commit/4d61e6e3b802399be62a521d6fa785698cb670b5


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

Hi Eric, I'm sorry but I had to revert your recent work. It introduced 
regressions in at least in test_io and test_multiprocessing_spawn on Windows 
and FreeBSD. I simply don't have the bandwidth to investigate this regression 
yet, whereas we really need the CI to remain stable to catch other regressions 
(the master branch received multiple new features recently, and there are some 
other regressions by that way ;-)).

test_multiprocessing_spawn is *very* hard to reproduce on FreeBSD, but I can 
reliably reproduce it. It just takes time. The issue is a crash producing a 
coredump. I consider that the bug is important enough to justify a revert.

The revert is an opportunity to seat down and track the root cause rather than 
urging to push a "temporary" quickfix. This bug seems to be very deep in the 
Python internals: thread state during Python shutdown. So it will take time to 
fully understand it and fix it (or redesign your recent changes, I don't know).

Tell me if you need my help to reproduce the bug. The bug has been seen on 
FreeBSD but also Windows:

* test_multiprocessing_spawn started to produce coredumps on FreeBSD: 
https://bugs.python.org/issue36114
* test_multiprocessing_spawn started to fail randomly on Windows: 
https://bugs.python.org/issue36116
* test_io started to fail randomly on Windows: 
https://bugs.python.org/issue36177

-- The Night's Watch

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

> The commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 introduced a regression 
> in 
> test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart:
>  bpo-36114.

There is a very similar bug on Windows: bpo-36116.

I'm now also quite confident that bpo-36177 is also a regression caused by this 
issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +12157

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

The commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 introduced a regression in 
test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart:
 bpo-36114.

Would it be possible to revert it until the bug is properly understood and 
fixed?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

> I suspect changes for this issue may be creating test_io failures on my 
> windows builders, (...)

I created bpo-36177 to track this regression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[David Bolen]

David Bolen  added the comment:

If I can help with testing or builder access or anything just let me know.  It 
appears that I can pretty reliably trigger the error through just the 
individual tests (test_daemon_threads_shutdown_std{out,err}_deadlock) in 
isolation, which is definitely less tedious than a full buildbot run to test a 
change.

BTW, while not directly related since it was only just merged, and I won't 
pretend to have any real understanding of the changes here, I do have a 
question about PR 12024 ... it appears HEAD_UNLOCK is used twice in 
_PyInterpreterState_LookUpID.  Shouldn't one of those be HEAD_LOCK?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

I've merged the PR for hoisting eval_breaker before the ceval loop starts.  
@Raymond, see if that addresses the performance regression you've been seeing.

I'll close this issue after I've sorted out the buildbot issues David mentioned 
(on his Windows builders).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:


New changeset bda918bf65a88560ec453aaba0758a9c0d49b449 by Eric Snow in branch 
'master':
bpo-33608: Simplify ceval's DISPATCH by hoisting eval_breaker ahead of time. 
(gh-12062)
https://github.com/python/cpython/commit/bda918bf65a88560ec453aaba0758a9c0d49b449


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:


New changeset b05b711a2cef6c6c381e01069dedac372e0b9fb2 by Eric Snow in branch 
'master':
bpo-33608: Use _Py_AddPendingCall() in _PyCrossInterpreterData_Release(). 
(gh-12024)
https://github.com/python/cpython/commit/b05b711a2cef6c6c381e01069dedac372e0b9fb2


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[David Bolen]

David Bolen  added the comment:

I suspect changes for this issue may be creating test_io failures on my windows 
builders, most notably my x86 Windows 7 builder where test_io has been failing 
both attempts on almost all builds.  It fails with a lock failure during 
interpreter shutdown, and commit ef4ac967 appears the most plausible commit out 
of the set introduced at the first failing build on Feb 24.

See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first 
failure.  test_io has failed both attempts on all but 3 of the subsequent 16 
tests of the 3.x branch.

It might be worth noting that this builder is slow, so if there are timeouts 
involved or a race condition of any sort it might be triggering it more readily 
than other builders.  I do, however, see the same failures - albeit less 
frequently and not usually on both tries - on the Win8 and Win10 builders.

For what it's worth one other oddity is that while having test_multiprocessing* 
failures are relatively common on the Win7 builder during the first round of 
tests due to exceeding the timeout, they usually pass on the retry, but over 
this same time frame have begun failing - not due to timeout - even on the 
second attempt, which is unusual.  It might be coincidental but similar 
failures are also showing up sporadically on the Win8/Win10 builders where such 
failures are not common at all.

--
nosy: +db3l

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +12086

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

FYI, I have a couple of small follow-up changes to land before I close this 
issue.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

STINNER Victor  added the comment:

> ...so it doesn't appear that my PR introduces a performance regression.

IMHO there is no performance regression at all. Just noice in the result which 
doesn't come with std dev.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

...so it doesn't appear that my PR introduces a performance regression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

Here's what I did (more or less):

$ python3 -m pip install --user perf
$ python3 -m perf system tune
$ git clone g...@github.com:python/performance.git
$ git clone g...@github.com:python/cpython.git
$ cd cpython
$ git checkout ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465
$ ./configure
$ make -j8
$ ./python ../performance/pyperformance run --fast --output speed.after
$ git checkout HEAD^
$ make -j8
$ ./python ../performance/pyperformance run --fast --output speed.before
$ ./python ../performance/pyperformance compare speed.before speed.after -O 
table

Here are my results:

speed.before


Performance version: 0.7.0
Report on Linux-4.15.0-45-generic-x86_64-with-glibc2.26
Number of logical CPUs: 4
Start date: 2019-02-25 20:39:44.151699
End date: 2019-02-25 20:48:04.817516

speed.after
===

Performance version: 0.7.0
Report on Linux-4.15.0-45-generic-x86_64-with-glibc2.26
Number of logical CPUs: 4
Start date: 2019-02-25 20:29:56.610702
End date: 2019-02-25 20:38:11.667461

+-+--+-+--+---+
| Benchmark   | speed.before | speed.after | Change   | 
Significance  |
+=+==+=+==+===+
| 2to3| 447 ms   | 440 ms  | 1.02x faster | Not 
significant   |
+-+--+-+--+---+
| chaos   | 155 ms   | 156 ms  | 1.01x slower | Not 
significant   |
+-+--+-+--+---+
| crypto_pyaes| 154 ms   | 152 ms  | 1.01x faster | Not 
significant   |
+-+--+-+--+---+
| deltablue   | 10.7 ms  | 10.5 ms | 1.01x faster | Not 
significant   |
+-+--+-+--+---+
| django_template | 177 ms   | 172 ms  | 1.03x faster | 
Significant (t=3.66)  |
+-+--+-+--+---+
| dulwich_log | 105 ms   | 106 ms  | 1.01x slower | Not 
significant   |
+-+--+-+--+---+
| fannkuch| 572 ms   | 573 ms  | 1.00x slower | Not 
significant   |
+-+--+-+--+---+
| float   | 149 ms   | 146 ms  | 1.02x faster | Not 
significant   |
+-+--+-+--+---+
| go  | 351 ms   | 349 ms  | 1.00x faster | Not 
significant   |
+-+--+-+--+---+
| hexiom  | 14.6 ms  | 14.4 ms | 1.01x faster | Not 
significant   |
+-+--+-+--+---+
| html5lib| 126 ms   | 122 ms  | 1.03x faster | 
Significant (t=3.46)  |
+-+--+-+--+---+
| json_dumps  | 17.6 ms  | 17.2 ms | 1.02x faster | 
Significant (t=2.65)  |
+-+--+-+--+---+
| json_loads  | 36.4 us  | 36.1 us | 1.01x faster | Not 
significant   |
+-+--+-+--+---+
| logging_format  | 15.2 us  | 14.9 us | 1.02x faster | Not 
significant   |
+-+--+-+--+---+
| logging_silent  | 292 ns   | 296 ns  | 1.01x slower | Not 
significant   |
+-+--+-+--+---+
| logging_simple  | 13.7 us  | 13.4 us | 1.02x faster | Not 
significant   |
+-+--+-+--+---+
| mako| 22.9 ms  | 22.5 ms | 1.02x faster | Not 
significant   |
+-+--+-+--+---+
| meteor_contest  | 134 ms   | 134 ms  | 1.00x faster | Not 
significant   |
+-+--+-+--+---+
| nbody   | 157 ms   | 161 ms  | 1.03x slower | 
Significant (t=-3.85) |
+-+--+-+--+---+
| 

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

At least, it *might* be a performance regression.  Here are the two commits I 
tried:

after:  ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 (PR #11617, from this issue)
before:  463572c8beb59fd9d6850440af48a5c5f4c0c0c9 (the one right before)

After building each (a normal build, not debug), I ran the micro-benchmark 
Raymond referred to ("./python Tools/scripts/var_access_benchmark.py") multiple 
times.  There was enough variability between runs from the same commit that I'm 
uncertain at this point if there really is any performance regression.  For the 
most part the results between the two commits are really close.  Also, the 
results from the "after" commit fall within the variability I've seen between 
runs of the "before" commit.

I'm going to try with the "performance" suite 
(https://github.com/python/performance) to see if it shows any regression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

GH-11617 has introduces a slight performance regression which will need to be 
resolved.  If I can't find the problem right away then I'll probably 
temporarily revert the commit.

See https://mail.python.org/pipermail/python-dev/2019-February/156451.html.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +12057

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:


New changeset ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 by Eric Snow in branch 
'master':
bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). 
(GH-11617)
https://github.com/python/cpython/commit/ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +11360, 11361

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +11360, 11361, 11362

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
pull_requests: +11360

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Johan Dahlin]

Change by Johan Dahlin :


--
nosy: +Johan Dahlin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Eric Snow  added the comment:

@Neil, we're definitely on the same page.  In fact, in a world where 
subinterpreters do not share a GIL, we can't ever use an object in one 
interpreter that was created in another (due to thread safety on refcounts).  
The role of "tightly controlling" passing/sharing objects (for a very loose 
definition of "sharing") falls to the channels described in PEP 554. [1]

However, there are several circumstances where interpreters may collaborate 
that involves one holding a reference (but not using it) to an object owned by 
the other.  For instance, see PyBuffer_Release(). [2]  This issue is about 
addressing that situation safely.  It is definitely not about safely using 
objects from other interpreters.

[1] The low-level implementation, including channels, already exists in 
Modules/_xxsubinterpretersmodule.c.
[2] https://docs.python.org/3/c-api/buffer.html#c.PyBuffer_Release

--
assignee:  -> eric.snow

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Neil Schemenauer]

Neil Schemenauer  added the comment:

I would suggest that sharing of objects between interpreters should be stamped 
out.  Could we have some #ifdef debug checking that would warn or assert so 
this doesn't happen?  I know currently we share a lot of objects.  However, in 
the long term, that does not seem like the correct design.  Instead, each 
interpreter should have its own objects and any passing or sharing should be 
tightly controlled.

--
nosy: +nascheme

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
keywords: +patch
pull_requests: +8758
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Eric Snow]

Change by Eric Snow :


--
nosy: +emilyemorehouse

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[Nick Coghlan]

Nick Coghlan  added the comment:

Adding a low level callback based mechanism to ask another interpreter to do 
work seems like a good way to go to me.

As an example of why that might be needed, consider the case of sharing a 
buffer exporting object with another subinterpreter: when the memoryview in the 
subinterpreter is destroyed, it needs to request that the buffer view be 
released in the source interpreter that actually owns the original object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

[STINNER Victor]

Change by STINNER Victor :


--
title: Add a cross-interpreter-safe mechanism to indicate that an object may be 
destroyed. -> [subinterpreters] Add a cross-interpreter-safe mechanism to 
indicate that an object may be destroyed.

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com