Skip to content

Acquire tokio mutex before spawn_blocking#112

Open
jprendes wants to merge 1 commit intohyperlight-dev:mainfrom
jprendes:avoid-locking-in-threads
Open

Acquire tokio mutex before spawn_blocking#112
jprendes wants to merge 1 commit intohyperlight-dev:mainfrom
jprendes:avoid-locking-in-threads

Conversation

@jprendes
Copy link
Copy Markdown
Contributor

Avoid wasting threads waiting for mutexes to lock, do the lock operation using async instead.

@jprendes jprendes added the kind/refactor Code refactoring label Apr 14, 2026
…ads while waiting for locks

Signed-off-by: Jorge Prendes <jorge.prendes@gmail.com>
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull request overview

This PR changes LoadedJSSandboxWrapper locking so the mutex is acquired asynchronously before entering spawn_blocking, reducing wasted blocking threads that would otherwise sit waiting on the lock. This fits into js-host-api’s Node-facing wrapper layer by improving how long-running guest execution serializes access to the underlying sandbox.

Changes:

  • Switch LoadedJSSandboxWrapper.inner from std::sync::Mutex to tokio::sync::Mutex.
  • Add helper methods (with_inner, with_blocking_inner, take_inner_with, take_blocking_inner_with) to centralize async-lock + blocking-work patterns.
  • Refactor call_handler, snapshot, restore, unload, and dispose to use the new helpers.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread src/js-host-api/src/lib.rs
Comment thread src/js-host-api/src/lib.rs
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

kind/refactor Code refactoring

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants