GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — stdlib: fix data race compiling a shared ModuleImpl by drew-512 · Pull Request #268 · go-python/gpython

Conversation

@drew-512

@drew-512 drew-512 commented Nov 10, 2026 •
edited
Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link
Copy Markdown
Contributor

ModuleInit compiles ModuleImpl.CodeSrc (or unmarshals CodeBuf) into ModuleImpl.Code on first use, without any locking. A registered ModuleImpl is shared by every py.Context, so when several contexts import such a module for the first time at once they race on impl.Code and on the py.Code still being built. go test -race with 8 contexts importing one CodeSrc module reports 25–26 races per run on main.

The code is now prepared in a small moduleCode helper under a package-level mutex. It is still compiled once and then shared, since a built py.Code is read-only (the multi-context example already relies on that). The mutex is only held while checking or building impl.Code.

Tests:

  • new stdlib/moduleinit_test.go: 8 contexts import a registered CodeSrc module at the same time and call into it. Fails under -race on main, 0 races in 60 runs on this branch.
  • go test -race ./... passes on Go 1.18, 1.19 and 1.27.

Fixes #266.

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions
@drew-512
stdlib: fix data race compiling a shared ModuleImpl
988383f
ModuleInit compiled ModuleImpl.CodeSrc (or unmarshalled CodeBuf) into
ModuleImpl.Code without synchronization. A registered ModuleImpl is
shared by every Context, so contexts importing such a module for the
first time at the same time raced on impl.Code and on the py.Code
being built.

Prepare the code under a package-level mutex. It is still compiled
once and then shared, since a built py.Code is read-only.
@drew-512
drew-512 force-pushed the stdlib-module-code-race branch from 645a9b4 to 988383f Compare November 10, 2026 00:58
@drew-512 drew-512 mentioned this pull request Nov 10, 2026
stdlib: resolve absolute script paths independently of sys.path #261
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

stdlib: data race importing a CodeSrc module from several contexts

Uh oh!

There was an error while loading. Please reload this page.

1 participant

@drew-512
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
You are visitor 01402503 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.