Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

GH-29021: Convert multiarray to multi-phase init (PEP 489)#29022

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
AA-Turner wants to merge1 commit intonumpy:main
base:main
Choose a base branch
Loading
fromAA-Turner:multi-phase/multiarray

Conversation

AA-Turner
Copy link

@AA-TurnerAA-Turner commentedMay 21, 2025
edited
Loading

@AA-Turner
Copy link
Author

The failures here are (will be) as the relevant parts ofnpy_static_pydata are not cleared on module deallocation, so e.g.npy_cpu_dispatch_tracer_init() and other functions checking the global state fail. We can add them_clear/m_free slots to the moduledef, but I'm not sure which bits we should reset.

The other option is to keep treating those variables as global and instead re-add the same object to the new module. This may cause other problems though, as I don't believe it's the intended execution model.

There also appears to be a SIGSEV around the call todtypemeta_wrap_legacy_descriptor() inarraytypes.c.src, but I'm not familiar enough with the templating process here.

cc@ngoldbaum if you'd be able to suggest anything?

A

@AA-TurnerAA-Turnerforce-pushed themulti-phase/multiarray branch from4e8bb3c to760440bCompareMay 22, 2025 05:38
@AA-TurnerAA-Turnerforce-pushed themulti-phase/multiarray branch from760440b tof5eed00CompareMay 22, 2025 05:47
@seberg
Copy link
Member

Nice, will be great to make progress here!

We have a lot of global state, but much of it can probably just stay intact within the same interpreter (some cannot, e.g. because new singletons are created but this was always incorrect, so for a first start...).

So without multi-stage init, CPython would not run the module initially again if the so was already loaded (so deleting it fromsys.modules and importing again doesn't trigger a second init)?

One problem withdtypemeta_wrap_legacy_descriptor is that it mutates global singleton instances. The actual problem should be indtypemeta_wrap_legacy_descriptor indtypemeta.c.

There is a check to catch types that are set to bad values, I honestly don't remember why it is there, and the loop definitely looks bad (it should just look up the type number of themdescr and not loop!).
So it may just be replacing the loop withPyArray_DescrFromType(descr->type_num);.

So long we don't actually support subinterpreters, the old type object should actually be good to use.@AA-Turner maybe you can try applying something like this:

diff --git a/numpy/_core/src/multiarray/dtypemeta.c b/numpy/_core/src/multiarray/dtypemeta.cindex 0b1b0fb391..adb268097c 100644--- a/numpy/_core/src/multiarray/dtypemeta.c+++ b/numpy/_core/src/multiarray/dtypemeta.c@@ -1075,6 +1075,11 @@ dtypemeta_wrap_legacy_descriptor(     _PyArray_LegacyDescr *descr, PyArray_ArrFuncs *arr_funcs,     PyTypeObject *dtype_super_class, const char *name, const char *alias) {+    if (Py_TYPE(descr) != NULL && NPY_DTYPE(descr)->singleton == (PyArray_Descr *)descr) {+        /* We seem to already have created a type, multiple inits? */+        return 0;+    }+     int has_type_set = Py_TYPE(descr) == &PyArrayDescr_Type;      if (!has_type_set) {

(but there will likely be a long tail of these type of things, and of course the real fix will be to move the singletons into proper module state!)

AA-Turner reacted with thumbs up emoji

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@AA-Turner@seberg

[8]ページ先頭

©2009-2025 Movatter.jp