Fix `vm.create` child VMs missing native libs and make spawned runtimes libuv-safe by Nicell · Pull Request #692 · luau-lang/lute

Nicell · 2025-12-14T08:40:25Z

Summary

This PR fixes a regression introduced in 0.1.0-nightly.20251020 where vm.create() child VMs did not have native @lute/* modules registered (e.g. @lute/net). As a result, child VMs would fall back to definitions/*.luau and error with "not implemented" (repro: examples/parallel_serve.luau). Closes #691.

Additionally, once child VMs can load native libraries again, multiple runtimes running on different OS threads must not share and concurrently drive uv_default_loop(). This PR gives each spawned runtime its own libuv loop and wires the native libraries to use the runtime’s loop.

User-visible fixes

examples/parallel_serve.luau works again (no longer hits definitions/net.luau: not implemented when running @lute/net inside a vm.create() VM).
Spawned VMs that use libuv-backed native libraries (net/task/fs/process/io) no longer rely on the process-global default loop across multiple threads.

Key changes

lute/vm/src/spawn.cpp
- Register native @lute/* modules in child VMs (matching the main CLI runtime behavior).
- Spawned runtimes allocate a dedicated libuv loop and are registered for process-lifetime tracking.
lute/runtime/include/lute/runtime.h, lute/runtime/src/runtime.cpp
- Runtime now owns an optional dedicated uv_loop_t and exposes getUvLoop().
- Added a small spawned-runtime registry (registerSpawnedRuntime, waitForSpawnedRuntimes) so the CLI can stay alive while spawned runtimes still have work.
lute/cli/src/climain.cpp
- After the main script finishes, wait for spawned runtimes to stop having work (since child VMs no longer contribute to uv_default_loop() activity).
libuv-backed libraries now use the calling runtime’s loop instead of uv_default_loop():
- lute/net/src/net.cpp (also minimal locking around global server maps for multi-VM access)
- lute/task/src/task.cpp
- lute/fs/src/fs.cpp, lute/fs/src/fs_impl.cpp
- lute/process/src/process.cpp
- lute/io/src/io.cpp

Tests

Added regression coverage for vm.create() module loading:
- tests/src/vmcreate.test.cpp
- tests/src/vm/vm_requirer.luau
- tests/src/vm/vm_helper.luau

Repro / Verification

Repro (previously failed on 20251020+):
lute tools/luthier.luau run lute -- ./examples/parallel_serve.luau
Run tests:
lute tools/luthier.luau run Lute.Test

Notes

This avoids undefined behavior from multiple runtime threads concurrently creating handles on and calling uv_run() on the single process-global uv_default_loop() (and the associated uWebSockets loop).

This was worked on by Codex for an hour, neat. I need to spend some time reviewing everything before opening this from draft

@Nicell

…uteVfs` (#696) Resolves #691. As @Nicell points out in #692, we have some libuv memory safety issues that have been revealed with this change, so they'll need to be fixed outside of this PR.

aatxe · 2026-01-06T21:13:59Z

cc @vrn-sn this isn't obsoleted by the changes you made, right?

vrn-sn · 2026-01-06T21:28:27Z

cc @vrn-sn this isn't obsoleted by the changes you made, right?

Partially, this part is solved by my previous PR:

Register native @lute/* modules in child VMs (matching the main CLI runtime behavior).

The rest of the logic in this PR that relates to libuv is unrelated to what I merged in.

Vighnesh-V · 2026-01-07T23:32:18Z

Left some preliminary feedback - I think with Varuns PR we can make this one considerably smaller.

This avoids undefined behavior from multiple runtime threads concurrently creating handles on and calling uv_run() on the single process-global uv_default_loop() (and the associated uWebSockets loop).

I'm not sure there is undefined behaviour - the default loop is single threaded right? So each coroutine only runs on the main thread, and continuations are only processed in the main thread when uv_run is called.

Vighnesh-V · 2026-01-07T23:01:43Z

lute/runtime/include/lute/runtime.h

 #include <vector>

 struct lua_State;
+struct uv_loop_s;


This is an internal libuv type - you'll want to store uv_loop_t

Vighnesh-V · 2026-01-07T23:02:11Z

lute/runtime/include/lute/runtime.h

    ~Runtime();

+    bool useDedicatedUvLoop();
+    uv_loop_s* getUvLoop() const;


Suggested change

uv_loop_s* getUvLoop() const;

uv_loop_t* getUVLoop() const;

Vighnesh-V · 2026-01-07T23:02:48Z

lute/runtime/include/lute/runtime.h


    std::atomic<int> activeTokens;
+
+    bool ownsUvLoop = false;


We could do one runtime, one loop - see my comment below, since we might not actually need this?

Vighnesh-V · 2026-01-07T23:04:32Z

lute/runtime/include/lute/runtime.h

+    // Event loop for this runtime; defaults to `uv_default_loop()`, but can be dedicated via `useDedicatedUvLoop`.
+    uv_loop_s* uvLoop = nullptr;


This adds a lot of complexity. Instead of defaulting, just initialize a uv_loop manually for this runtime.

Vighnesh-V · 2026-01-07T23:11:15Z

lute/runtime/src/runtime.cpp

+    if (ownsUvLoop)
+        return true;
+
+    uv_loop_t* loop = new uv_loop_t();


can move into the RuntimeConstructor, along with the uv_loop_init call.

Vighnesh-V · 2026-01-07T23:12:38Z

lute/runtime/src/runtime.cpp

+static std::mutex spawnedRuntimeMutex;
+static std::vector<std::weak_ptr<Runtime>> spawnedRuntimes;


These shouldn't be static data( I don't think we need a mutex here either?) Each runtime is going to be on it's own event loop.

Vighnesh-V · 2026-01-07T23:13:44Z

lute/fs/src/fs.cpp

 {
    uv_fs_t unlink_req;
-    int err = uv_fs_unlink(uv_default_loop(), &unlink_req, luaL_checkstring(L, 1), nullptr);
+    uv_loop_t* loop = reinterpret_cast<uv_loop_t*>(getRuntime(L)->getUvLoop());


Probably don't want to re-interpret cast here - this should just be a uv_loop_t.

ditto for all the places below.

Nicell added 2 commits December 14, 2025 00:37

VM fixes

4c19f0e

fixes

4834e3d

vrn-sn mentioned this pull request Dec 16, 2025

Enables the @lute libraries in spawned VMs by implementing a new LuteVfs #696

Merged

aatxe requested a review from vrn-sn January 6, 2026 21:14

Vighnesh-V requested changes Jan 7, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comments

Fix `vm.create` child VMs missing native libs and make spawned runtimes libuv-safe#692

Fix `vm.create` child VMs missing native libs and make spawned runtimes libuv-safe#692
Nicell wants to merge 2 commits intoluau-lang:primaryfrom
Nicell:vm-fixes

Nicell commented Dec 14, 2025 •

edited

Loading

Uh oh!

aatxe commented Jan 6, 2026

Uh oh!

vrn-sn commented Jan 6, 2026

Uh oh!

Vighnesh-V commented Jan 7, 2026 •

edited

Loading

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Vighnesh-V Jan 7, 2026 •

edited

Loading

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Vighnesh-V Jan 7, 2026 •

edited

Loading

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Vighnesh-V Jan 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

		// Event loop for this runtime; defaults to `uv_default_loop()`, but can be dedicated via `useDedicatedUvLoop`.
		uv_loop_s* uvLoop = nullptr;

		static std::mutex spawnedRuntimeMutex;
		static std::vector<std::weak_ptr<Runtime>> spawnedRuntimes;

Comments

Conversation

Nicell commented Dec 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

User-visible fixes

Key changes

Tests

Repro / Verification

Notes

Uh oh!

aatxe commented Jan 6, 2026

Uh oh!

vrn-sn commented Jan 6, 2026

Uh oh!

Vighnesh-V commented Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Vighnesh-V Jan 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Nicell commented Dec 14, 2025 •

edited

Loading

Vighnesh-V commented Jan 7, 2026 •

edited

Loading

Vighnesh-V Jan 7, 2026 •

edited

Loading

Vighnesh-V Jan 7, 2026 •

edited

Loading