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-45944: Avoid calling isatty() for most open() calls#29870

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

Closed
collinanderson wants to merge2 commits intopython:mainfromcollinanderson:45944

Conversation

@collinanderson
Copy link

@collinandersoncollinanderson commentedDec 1, 2021
edited by bedevere-bot
Loading

https://bugs.python.org/issue45944

isatty() is a system call on linux. Most open()s are files, and we're already getting the size of the file. If it has a size, then we know it's not a atty, and can avoid calling it.

https://bugs.python.org/issue45944

Copy link
Member

@tirantiran left a comment

Choose a reason for hiding this comment

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

That's a clever hack!

I made a few suggestions to use correctPy_ssize_t everwhere.


charrawmode[6],*m;
intline_buffering,is_number;
__int64_tsize=0;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
__int64_tsize=0;
Py_ssize_tsize=0;

size_obj=_PyObject_GetAttrId(raw,&PyId__size);
if (size_obj==NULL)
gotoerror;
size=PyLong_AsLongLong(size_obj);
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
size=PyLong_AsLongLong(size_obj);
size=PyLong_AsSsize_t(size_obj);

unsignedintclosefd :1;
charfinalizing;
unsignedintblksize;
__int64_tsize;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
__int64_tsize;
Py_ssize_tsize;

Choose a reason for hiding this comment

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

It should beoff_t. The file size can exceed thePy_ssize_t range.

Copy link
Member

Choose a reason for hiding this comment

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

You are right! size handling depends on platform and support for large file support. You can copy the approach fromposixmodule.c:

#ifdef MS_WINDOWS    typedef long long Py_off_t;#else    typedef off_t Py_off_t;#endif
#ifdef HAVE_LARGEFILE_SUPPORT    size = (Py_off_t)PyLong_AsLongLong(arg);#else    size = (Py_off_t)PyLong_AsLong(arg);#endif

Choose a reason for hiding this comment

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

It is too complicated, we need to duplicate this in several files. But it may be simpler if only cache the boolean result (st_size == 0 orS_IFCHR()) as_maybeatty. Then the size ofoff_t does not matter.

if (fdfstat.st_blksize>1)
self->blksize=fdfstat.st_blksize;
#endif/* HAVE_STRUCT_STAT_ST_BLKSIZE */
self->size=fdfstat.st_size;
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
self->size=fdfstat.st_size;
self->size=fdfstat.st_size;


staticPyMemberDeffileio_members[]= {
{"_blksize",T_UINT, offsetof(fileio,blksize),0},
{"_size",T_UINT, offsetof(fileio,size),0},
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
{"_size",T_UINT, offsetof(fileio,size),0},
{"_size",T_PYSSIZET, offsetof(fileio,size),0},

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actionsgithub-actionsbot added the staleStale PR or inactive for long period of time. labelJan 1, 2022
@eendebakpt
Copy link
Contributor

@collinanderson The PR has gone stale. Can you address the review comments? Or are you ok will someone else picking this up?

@bedevere-app
Copy link

Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

@cmaloney
Copy link
Contributor

I think this can be closed now as a fix forbpo-45944 /gh-90102 has been committed and the issue closed out

@skirpichev
Copy link
Contributor

(And there is no signs of life anyway...)

@collinanderson
Copy link
Author

collinanderson commentedOct 8, 2024
edited
Loading

Ohh awesome. Thank you! Yeah Sorry I'm not much of a C programmer. I'm super excited to see#120754 syscalls being optimized.

cmaloney reacted with hooray emoji

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

Reviewers

@tirantirantiran left review comments

@serhiy-storchakaserhiy-storchakaserhiy-storchaka left review comments

Assignees

No one assigned

Labels

awaiting reviewstaleStale PR or inactive for long period of time.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

9 participants

@collinanderson@eendebakpt@cmaloney@skirpichev@tiran@serhiy-storchaka@the-knights-who-say-ni@ezio-melotti@bedevere-bot

[8]ページ先頭

©2009-2025 Movatter.jp