Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Use _Py_atomic API for concurrency-sensitive signal state #74991

Closed
pitrou opened this issue Jun 29, 2017 · 5 comments
Closed

Use _Py_atomic API for concurrency-sensitive signal state #74991

pitrou opened this issue Jun 29, 2017 · 5 comments
Labels
3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@pitrou
Copy link
Member

pitrou commented Jun 29, 2017

BPO 30808
Nosy @pitrou, @vstinner
PRs
  • bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state #2417
  • [3.6] bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (GH-2417) #3007
    		•

    Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
closed_at = <Date 2017-07-17.10:25:40.121>
created_at = <Date 2017-06-29.20:01:06.342>
labels = ['interpreter-core', 'type-feature', '3.7']
title = 'Use _Py_atomic API for concurrency-sensitive signal state'
updated_at = <Date 2017-08-06.17:32:41.763>
user = 'https://github.com/pitrou'

    bugs.python.org fields:

    activity = <Date 2017-08-06.17:32:41.763>
actor = 'pitrou'
assignee = 'none'
closed = True
closed_date = <Date 2017-07-17.10:25:40.121>
closer = 'pitrou'
components = ['Interpreter Core']
creation = <Date 2017-06-29.20:01:06.342>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 30808
keywords = []
message_count = 5.0
messages = ['297304', '297313', '297315', '298478', '299806']
nosy_count = 4.0
nosy_names = ['pitrou', 'vstinner', 'jyasskin', 'neologix']
pr_nums = ['2417', '3007']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue30808'
versions = ['Python 3.7']
    @pitrou
    Copy link
    Member Author

    pitrou commented Jun 29, 2017

    We already use the _Py_atomic APIs in ceval.c, for lockless boolean flags. We should do the same in the signal module where there are similar concurrency issues (for example between the signal handler running in one thread and PyErr_CheckSignals running in another thread).

    @pitrou pitrou added 3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement labels Jun 29, 2017
    @vstinner
    Copy link
    Member

    There is a sig_atomic_t type. Should we use that one?
    https://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html

    "To avoid uncertainty about interrupting access to a variable, you can use a particular data type for which access is always atomic: sig_atomic_t. Reading and writing this data type is guaranteed to happen in a single instruction, so there’s no way for a handler to run “in the middle” of an access."

    @pitrou
    Copy link
    Member Author

    pitrou commented Jun 29, 2017

    Look at the PR :-) That's what we used. But, while sig_atomic_t guarantees that accesses are atomic, it doesn't enforce a memory order. So the CPU (depending on the architecture) is free to reorder writes.

    @pitrou
    Copy link
    Member Author

    pitrou commented Jul 17, 2017

    New changeset 2c8a5e4 by Antoine Pitrou in branch 'master':
    bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (bpo-2417)
    2c8a5e4

    @pitrou pitrou closed this as completed Jul 17, 2017
    @pitrou
    Copy link
    Member Author

    pitrou commented Aug 6, 2017

    New changeset 57e836c by Antoine Pitrou in branch '3.6':
    [3.6] bpo-30808: Use _Py_atomic API for concurrency-sensitive signal state (GH-2417) (bpo-3007)
    57e836c

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @vstinner vstinner mentioned this issue Oct 6, 2023
    Merged
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees
    No one assigned
    Labels
    3.7 (EOL) end of life interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Milestone
    No milestone
    Development

    No branches or pull requests
    2 participants
    @vstinner @pitrou