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

gh-133885: Disallow sharing zstd (de)compressor contexts#134253

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

emmatyping
Copy link
Member

@emmatypingemmatyping commentedMay 19, 2025
edited by bedevere-appbot
Loading

It is not possible to share Zstandard objects across thread boundaries. To resolve this, we check if the object was created on the current thread and raise aRuntimeError if it is not. Wasn't totally sure what exception to raise to communicate the issue, so ifRuntimeError isn't correct, please suggestion another option.

The tests are updated to ensure that the error is raised if a (de)compression context is shared across threads.

(as requested, cc@ngoldbaum )

According to the zstd author, it is not possible to share Zstandard objects across thread boundaries. To resolve this, we check if the object was created on the current thread and raise a RuntimeError if it is not.The tests are updated to ensure that the error is raised if a (de)compression context is shared across threads.
@@ -52,4 +52,21 @@ extern void
set_parameter_error(const _zstd_state* const state, int is_compress,
int key_v, int value_v);

static inline int
check_object_shared(PyObject *ob, char *type)
Copy link
Member

Choose a reason for hiding this comment

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

I think this is probably not be the right way to implement this check? Access from different threads could happen regardless of free-threading builds.

I think the concept the extension module might want to enforce is something like getting the current thread id (we have a python c api for this IIRC) upon first "use" of the object, saving that in the object state, and checking that current thread id == that thread id for subsequent uses.

first use could be construction... but unless the zstandard C API requires that, it may be better to consider first use the first time that ZStdCompressor is actually used by a C API. This allows for the pattern of:

A compressor or decompressor is created by one thread - and added to a thread pool or work queue to be actually used and exhausted - exclusively - in another thread.

@emmatyping
Copy link
MemberAuthor

After talking with Thomas, I think I'm going to try a different approach.

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

@gpsheadgpsheadgpshead left review comments

Assignees
No one assigned
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

2 participants
@emmatyping@gpshead

[8]ページ先頭

©2009-2025 Movatter.jp