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

Conditionally compile the pthread_t member in emscripten::val#25872

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
xbcnn wants to merge1 commit intoemscripten-core:main
base:main
Choose a base branch
Loading
fromxbcnn:val_pthread

Conversation

@xbcnn
Copy link
Contributor

val adds apthread_t data member for later thread checks, but it is only used when the code is compiled with pthread support.

Following the "what you don't use, you don't pay for" principle, this change wraps thepthread_t member with the same#ifdef guard used by the thread-checking code. For single-threaded builds, the member is omitted entirely, thus avoiding unnecessary memory overhead.

val adds a `pthread_t` data member for later thread checks, but it is onlyused when the code is compiled with pthread support.Following the "what you don't use, you don't pay for" principle, thischange wraps the `pthread_t` member with the same `#ifdef` guard used bythe thread-checking code. For single-threaded builds, the member is omittedentirely, thus avoiding unnecessary memory overhead.
@xbcnn
Copy link
ContributorAuthor

@RReverser@sbc100 Please help review. Thanks.

@sbc100
Copy link
Collaborator

It the extra word really a problem?

If it is significant should we also put this behindifndef _NDEBUG?

@xbcnn
Copy link
ContributorAuthor

I think it is not significant if not widely used. However, when you have thousands of them, the cumulative memory overhead can become noticeable.

Guarding with#ifdef _REENTRANT is more proper here because it directly emphasizes the connection to-pthread, which is why we add it.

@RReverser
Copy link
Collaborator

I remember in the original PR where I added this field I was also initially guarding this field with a compilation guard, but@sbc100 suggested the extra complexity is not worth it as the size is fairly small.

I'm fine either way.

@sbc100
Copy link
Collaborator

I think only risk here is that different compilation units will end up with different stuct sizes.. which could be very bad

@RReverser
Copy link
Collaborator

I think only risk here is that different compilation units will end up with different stuct sizes.. which could be very bad

Oh right, I remember you mentioning that.

@xbcnn
Copy link
ContributorAuthor

I remember in the original PR where I added this field I was also initially guarding this field with a compilation guard

I didn't notice that when I made this PR.

I think only risk here is that different compilation units will end up with different stuct sizes.. which could be very bad

Normally this won't happen if entire application is built from source. But for prebuilt libs, there could be subtle bugs.., if
they built with and without-pthread.

@RReverser
Copy link
Collaborator

Normally this won't happen if entire application is built from source. But for prebuilt libs, there could be subtle bugs.., if they built with and without-pthread.

Even for building from source, you can build some objects / libraries with-pthread and others without.

When you link them together (mix & match is allowed), it will result in incompatible struct layouts, which is going to lead to memory corruptions that will be rather hard to debug.

@xbcnn
Copy link
ContributorAuthor

Even for building from source, you can build some objects / libraries with-pthread and others without.

Yeah, even it is not common engineering practices.
BTW, I did run into a similar problem with skia and really it is hard to find out.

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

Reviewers

@RReverserRReverserAwaiting requested review from RReverser

At least 1 approving review is required to merge this pull request.

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@xbcnn@sbc100@RReverser@arbiny

[8]ページ先頭

©2009-2025 Movatter.jp