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

bpo-36876: Avoid static locals.#13372

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

Conversation

@ericsnowcurrently
Copy link
Member

@ericsnowcurrentlyericsnowcurrently commentedMay 17, 2019
edited by bedevere-bot
Loading

This patch touches a lot of files but does only two very specific things:

  • move static locals to global scope (if they aren't truly global)
  • move all locally scoped_Py_IDENTIFIER() to global scope

Moving these to global scope makes it easier to identify problematic usage viaTools/c-globals/check-c-globals.py. It also has the side effect of dropping a number of duplicate_Py_IDENTIFIER(), thus saving a little bit of space. :)

The overall objective is to eliminate any global state that isn't truly process-global (and to ensure the remaining global state is thread-safe). This is only one of the early steps.

https://bugs.python.org/issue36876

Copy link
Contributor

@asvetlovasvetlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

asyncio part looks good

mpd_setminalloc(mpd_ssize_tn)
{
staticintminalloc_is_set=0;
staticintminalloc_is_set=0;// Static is okay here (process-global).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Please don't changelibmpdec, even if it's just a comment. :)

Copy link
Member

@vstinnervstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

move all locally scoped _Py_IDENTIFIER() to global scope

I dislike this change. I prefer to keep "local" static variables in functions. I don't see how moving them as globals is solving any issue, apart your practical issue of detecting them with your tool.

I would prefer to see an API to support static variable per interpreter.

I would suggest to develop an hash table similar to thread TLS: each static variable would have a global unique identifier, and its value would stored in an hash table in the PyInterpreterState. The problem is how to initialize the global unique identifier in a safe way (thread safety / atomicity). But that could be implemented using "local static" variables.

@bedevere-bot
Copy link

When you're done making the requested changes, leave the comment:I have made the requested changes; please review again.

format_ctime(PyDateTime_Date*date,inthours,intminutes,intseconds)
{
staticconstchar*constDayNames[]= {
staticconstchar*constDayNames[]= {// Static is okay here (immutable data).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Are these comments really useful? To me, it seems obvious that static constants are safe. I'm not sure of the value of such comment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

A comment sounds useful to flag all local statics as "good" and for a linter that checks for unverified local static vars. I'm ok with the comments, but maybe a shorter one like// static ok.?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I agree with@vstinner. If you really want to keep these comments, please move them to separate lines to avoid noise when usinggit blame.

@vstinner
Copy link
Member

(...) The problem is how to initialize the global unique identifier in a safe way (thread safety / atomicity). But that could be implemented using "local static" variables.

I forgot to mention that "local static variables" would be easier to initialize properly, since they cannot be accessed before the function is called: before Python is initialized.

The case of global static variables is worse: we cannot statically initialize them, we need something to dynamically initialize them. Maybe at the first access?

About the global unique identifier, one solution would be to use the memory address of the variable: it should be unique. I don't see why a compiler would merge two variables.

Draft pseudo API:

void get_interpreter_specific(uintptr_t key, size_t size, void *value);int set_interpreter_specific(uintptr_t key, size_t size, void *value);#define PyStaticVariable(TYPE) static TYPE// FIXME: add assertion to ensure that VAR is a PyStaticVariable#define PyStaticVariable_get(VAR, VALUE) \   get_interpreter_specific((uintptr_t)&(VAR), sizeof(VAR), &(VALUE))#define PyStaticVariable_set(VAR, VALUE) \   set_interpreter_specific((uintptr_t)&(VAR), sizeof(VAR), &(VALUE))PyObject* func(void){PyStaticVariable(int) var;// if var doesn't exist in the interpreter local storage,// its value is always 0 by default, for any type,// as global static variables in Cint value;PyStaticVariable_get(var, value);value += 1;if (PyStaticVariable_set(var, value) < 0) { return NULL; }Py_RETURN_VALUE;}

Problem: we cannot pre-allocate the storage of "var" value into the interpreter "local storage" hash table, so set_interpreter_specific() can fail with a memory allocation failure :-(

@tiran
Copy link
Member

@ericsnowcurrently Please re-generate the ast module:

Generated files not up to date M Python/Python-ast.c

Copy link
Contributor

@skrahskrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

As Victor has also requested, I'd remove all comments that mention that variables are process local.

@bedevere-bot
Copy link

When you're done making the requested changes, leave the comment:I have made the requested changes; please review again.

Copy link
Member

@gpsheadgpshead left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

overall i'm a little concerned about how fragile this is. it won't be obvious in all code why something static lives outside of the only place it is used. it feels like we need a way to prevent future C code authors from making this mistake.

date_fromisocalendar(PyObject*cls,PyObject*args,PyObject*kw)
{
staticchar*keywords[]= {
staticchar*kwlist[]= {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

is there a reason all of the kwlist's everywhere cannot become static const? (lemme guess.. our C API complains about the type?)

returnNULL;
}
returnPyObject_GetAttr(im->im_func,docstr);
//if (cached_str___doc__ == NULL) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

checking in a block of commented out code looks wrong... what's up here?

_Py_IDENTIFIER(last_type);
_Py_IDENTIFIER(last_value);
_Py_IDENTIFIER(lineno);
_Py_IDENTIFIER(msg);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

could the _Py_IDENTIFIER macro be modified such that itonly works from the global scope so that these don't creep back into function bodies?

@ericsnowcurrently
Copy link
MemberAuthor

Thanks for all the feedback, everyone! I'm going to re-think this as you've all made good points. :) I may re-open the PR if it later makes sense to re-purpose it, but I'll probably instead tackle the statics in groups byModules/Objects/Python.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@vstinnervstinnervstinner requested changes

@tirantirantiran approved these changes

@gpsheadgpsheadgpshead requested changes

@asvetlovasvetlovasvetlov approved these changes

@1st11st1Awaiting requested review from 1st1

@berkerpeksagberkerpeksagAwaiting requested review from berkerpeksag

@brettcannonbrettcannonAwaiting requested review from brettcannon

@encukouencukouAwaiting requested review from encukou

@methanemethaneAwaiting requested review from methane

@ncoghlanncoghlanAwaiting requested review from ncoghlan

@rhettingerrhettingerAwaiting requested review from rhettinger

@warsawwarsawAwaiting requested review from warsaw

+1 more reviewer

@skrahskrahskrah requested changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@ericsnowcurrently@bedevere-bot@vstinner@tiran@berkerpeksag@gpshead@asvetlov@skrah@the-knights-who-say-ni

[8]ページ先頭

©2009-2025 Movatter.jp