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

fix(core): Fix race condition inSyncClient loop init#468

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
anubhav756 wants to merge1 commit intomain
base:main
Choose a base branch
Loading
fromanubhav-fix-sync-client-race

Conversation

@anubhav756
Copy link
Contributor

Fixes a race condition inToolboxSyncClient where multiple threads could initialize separate event loops, causingaiohttp to raiseRuntimeError.

This change adds a thread lock to ensure the shared background event loop is initialized exactly once.

Fixes#428

Copy link
Contributor

@kurtisvgkurtisvg left a comment

Choose a reason for hiding this comment

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

Somewhat concerned -- how did we hit this race condition? Doesn't the GIL prevent us from having to use a lock unless someone is multi-threading?

Fixes a race condition in ToolboxSyncClient where multiple threads could initialize separate event loops, causing aiohttp to raise RuntimeError.This change adds a thread lock to ensure the shared background event loop is initialized exactly once.
@anubhav756anubhav756force-pushed theanubhav-fix-sync-client-race branch frome71b6eb toc61a8faCompareDecember 18, 2025 11:48
@anubhav756
Copy link
ContributorAuthor

anubhav756 commentedDec 18, 2025
edited
Loading

Somewhat concerned -- how did we hit this race condition? Doesn't the GIL prevent us from having to use a lock unless someone is multi-threading?

It looks like the user is indeed using multi-threading here. Their stack trace shows usage ofconcurrent.futures, and they mentioned the error occurs when handling multiple session requests simultaneously (screenshot).

Since they are multi-threading, the GIL unfortunately doesn't protect us here.

Thoughts?

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

Reviewers

@kurtisvgkurtisvgkurtisvg approved these changes

@averikitschaverikitschAwaiting requested review from averikitsch

@twishabansaltwishabansalAwaiting requested review from twishabansal

Assignees

@anubhav756anubhav756

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Runtime error Timeout context manager should be used inside a task

2 participants

@anubhav756@kurtisvg

[8]ページ先頭

©2009-2025 Movatter.jp