Skip to content

Avoid recursive cache lock in SDL TTF ports - #27590

Open
brendandahl wants to merge 1 commit into
emscripten-core:mainfrom
brendandahl:sdl-cache
Open

Avoid recursive cache lock in SDL TTF ports#27590
brendandahl wants to merge 1 commit into
emscripten-core:mainfrom
brendandahl:sdl-cache

Conversation

@brendandahl

Copy link
Copy Markdown
Collaborator

When building port libraries, build_port compiles sources with emcc in a subprocess while the parent process holds EM_CACHE_IS_LOCKED. Passing -sUSE_* flags causes the child emcc to resolve ports and attempt to acquire the cache lock if dependencies like harfbuzz are not yet in the cache, causing an AssertionError.

Pass include directories directly instead of port settings flags when compiling SDL TTF port sources. Also ensure parent directories exist when writing port assets.

When building port libraries, build_port compiles sources with emcc in a
subprocess while the parent process holds EM_CACHE_IS_LOCKED. Passing
-sUSE_* flags causes the child emcc to resolve ports and attempt to
acquire the cache lock if dependencies like harfbuzz are not yet in the
cache, causing an AssertionError.

Pass include directories directly instead of port settings flags when
compiling SDL TTF port sources. Also ensure parent directories exist
when writing port assets.

@sbc100 sbc100 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

It looks like you are trying to fix this issue: #27160

Even though this change might fix the issue I don't think it should be necessary, because all ports always build their dependencies before building themselves.

Comment thread test/test_other.py
self.set_setting('USE_SDL', 2)
self.set_setting('USE_SDL_TTF', 2)
with shared.cache.lock('test_sdl_ttf_parent_cache_lock'):
ports.get_port_by_name('sdl2_ttf').get(ports.Ports, settings, shared)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I'd rather find a way to test this from outside using embuilder and/or emcc rather then using the internal API like this.

@sbc100

sbc100 commented Aug 22, 2026

Copy link
Copy Markdown
Collaborator

In other words, the assertion in question should never fire. At least when when N process are all trying to build the same ports.

The only time this assertion should ever fire is if another process deletes a ports right after the current process builds it. But being robust against the deletion of ports is not something I think we can ever really be robust against, and deleting ports while other folks are using the compiler seems like a situation that lead to crash like this.

The question is, how is it possible that the second process is deleting/clearing libsdl2 here:

Ports.clear_project_build(name)
.. after anther process just built it?

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants