[issue29842] Make Executor.map work with infinite/large inputs correctly
Change by Leonard Lausen : -- nosy: +leezu ___ Python tracker <https://bugs.python.org/issue29842> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39778] collections.OrderedDict and weakref.ref raises "refcount is too small" assertion
Change by Leonard Lausen : -- type: -> crash ___ Python tracker <https://bugs.python.org/issue39778> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39778] collections.OrderedDict and weakref.ref raises "refcount is too small" assertion
New submission from Leonard Lausen :
Below sample program, will raise "Modules/gcmodule.c:110: gc_decref: Assertion
"gc_get_refs(g) > 0" failed: refcount is too small" on Python 3.8.2 debug build.
On 3.7.6 debug build, "Modules/gcmodule.c:277: visit_decref: Assertion
`_PyGCHead_REFS(gc) != 0' failed." is raised.
```
import collections
import gc
import weakref
hooks_dict = collections.OrderedDict()
hooks_dict_ref = weakref.ref(hooks_dict)
gc.collect()
print('Hello world')
```
The complete error message on 3.8.2 debug build is
```
Modules/gcmodule.c:110: gc_decref: Assertion "gc_get_refs(g) > 0" failed:
refcount is too small
Memory block allocated at (most recent call first):
File "/home/$USER/test.py", line 6
object :
type: weakref
refcount: 1
address : 0x7ff788208a70
Fatal Python error: _PyObject_AssertFailed
Python runtime state: initialized
Current thread 0x7ff789f9c080 (most recent call first):
File "/home/$USER/test.py", line 7 in
zsh: abort PYTHONTRACEMALLOC=1 python ~/test.py
```
--
components: C API
messages: 362846
nosy: leezu
priority: normal
severity: normal
status: open
title: collections.OrderedDict and weakref.ref raises "refcount is too small"
assertion
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39778>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39660] Contextvars: Optional callbacks on state change
Leonard Lausen added the comment: > No, but there's C API that you can use to get/set contextvars. If a C library > is hard coded to use threadlocals I'm afraid there's nothing we can do about > it except fixing their C code to make state storage pluggable. I agree the C library could check the Python state. On the other hand, the Python frontend may be just one of multiple supported language frontends of the library. So it seems preferable if Python could tell the library when to change state. > What library do you have in mind? MXNet has such a thread-local C API to enable / disable recording for autograd. https://github.com/apache/incubator-mxnet/blob/9b38df0622fec677e6b4891dfc4c10295359996d/include/mxnet/c_api.h#L1260-L1266 > Theoretically yes, for debug purposes at least. But I still fail to see how > you could use that API even if it existed. Consider we are in "context 1". When we change the state in the C library by calling `old_state = lib.set_state(new_state)`, we get to know the prior state. When switching to "context 2", `lib.set_state(old_state)` should be called. When switching back to "context 1", `lib.set_state(new_state)` should be called again. It's analogous to contextvars. Would there be too much overhead if allowing specification of a python function that contextvars calls on context changes? -- ___ Python tracker <https://bugs.python.org/issue39660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39660] Contextvars: Optional callbacks on state change
Leonard Lausen added the comment: Consider a `lib = ctypes.CDLL(lib_path, ctypes.RTLD_LOCAL)` which provides APIs `lib.compute`, `lib.set_state` and a Python interface wrapping both in `def compute`, `def set_state`. Let's assume `lib.set_state` sets a thread-local state in the library implementation and further that the behaviour of `lib.compute` depends on the last call to `lib.set_state`. Users of the Python interface may call `set_state` and `compute` concurrently in coroutines. Thereby one coroutine may change the state in the library, prior to another coroutine calling `compute`. This leads to a wrong result. If `set_state` and `compute` were pure python functions, `contextvars` could be used to implement set_state and provide context-local state. Is there any existing API that can be used to call `lib.set_state` on context changes? If so, please let me know. If not, would it make sense to extend `contexvars` to allow users to configure that `lib.set_state` is called on context change? -- ___ Python tracker <https://bugs.python.org/issue39660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39660] Contextvars: Optional callbacks on state change
New submission from Leonard Lausen : contextvars provide APIs to manage, store, and access context-local state. Unfortunately, if Python is used as a frontend for a native libray (eg accessed via ctypes), and in case that the state of interest is managed in the native library, contextvar API is insufficient. To support native libraries, instead of simply exposing the current state via `contextvar.get()`, contextvar API could allow specification of callbacks to update the state in the native library. -- messages: 362118 nosy: leezu priority: normal severity: normal status: open title: Contextvars: Optional callbacks on state change versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue39660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30140] Binary arithmetic does not always call subclasses first
Change by Leonard Lausen : -- nosy: +leezu ___ Python tracker <https://bugs.python.org/issue30140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32485] Multiprocessing dict sharing between forked processes
Change by Leonard Lausen <leon...@lausen.nl>: -- nosy: +Leonard Lausen ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
