runtime: failed to create new OS thread

[vetptzru]

When trying to run tsgo against a large TypeScript project (approx. 56,000 files) located on a macFUSE volume, the Go runtime crashes with a runtime: failed to create new OS thread.
Monitoring the process reveals that tsgo spawns over 9,000 OS threads before it ultimately panics.

Steps to Reproduce:

1. Mount a large TypeScript project (~56,000 files) using macFUSE.
2. Run typescript-go against this project directory.
3. Track the thread count using Activity Monitor or ps.
4. Observe the process memory/thread explosion and the subsequent crash.

Actual Behavior:

The application spawns more than 9,000 threads and then crashes with the OS thread exhaustion error:

runtime: failed to create new OS thread

Environment:

• OS: MacOs 26.3.1
• File System: macFUSE 5.1.3
• Project Size: ~56,000 files
• TSGo Version: 0.20260303.1

[jakebailey]

I don't understand how this is possible; Go only spawns as many threads as physical cores, then maps tasks onto them. We don't do anything else to spawn threads, and we even limit concurrent IO, so the threads shouldn't even be locked doing that (not that they typically are anyway).

[DanielRosenwasser]

I guess on that note, do you see any differences if you pass a flag like --singleThreaded? And how are you building it today? Are you passing something like --watch?

[vetptzru]

I guess on that note, do you see any differences if you pass a flag like --singleThreaded?

Yes, there is a difference. When running with the --singleThreaded flag, the issue doesn't occur and everything works without crashing.

And how are you building it today?

Currently, I'm building it using the --singleThreaded flag. However, I'm not sure how to pass this flag in VS Code, as I'm experiencing the exact same tsgo crashes there.

Are you passing something like --watch?

No.

[vetptzru]

Here are some screenshots showing the peak thread count the tsgo process sometimes hits before crashing:

[vetptzru]

@DanielRosenwasser do you need any more information from me, or is this enough?

[jakebailey]

I don't know that this is actionable, we don't have a great way to reproduce it, or info that can help figure out why. Perhaps runtime tracing could show some info but if the process is hard exiting, I'm not sure how we'd get a failure out of it.

I also don't know how this issue has so many reactions in such a short amount of time; was this linked from somewhere?

[vetptzru]

I dug into the codebase to understand what's happening, and here's what I found:

Root cause:

The file parser spawns goroutines eagerly (one per file, recursively through the import graph), which works great on fast native filesystems. However, each goroutine blocks waiting to acquire readSema (cap 128) before reading a file. On slow filesystems like MacFUSE — where every read is a user-space IPC call — goroutines stay blocked significantly longer than usual. Since a goroutine blocked on a channel send holds an OS thread, the thread count grows faster than reads complete, eventually hitting the OS limit.

Relevant files:

• internal/core/workgroup.go:34–42 — parallelWorkGroup.Queue() spawns goroutines with no upper bound
• internal/compiler/filesparser.go:246–294 — start() recurses into subtasks inside already-queued goroutines, amplifying the effect
• internal/vfs/osvfs/os.go:81–89 — readSema blocks goroutines (and their OS threads) while waiting for a read slot

Worth noting: ThrottleGroup in workgroup.go already uses a semaphore-based approach, where the semaphore is acquired before spawning the goroutine rather than inside it. Wiring something similar into the file parser could help here.

Happy to provide more details or a reproduction if helpful.

Yes, I actually shared the link in our internal company chat. We are working on a large project with a lot of developers, and our team really wants to migrate to tsgo. However, this specific issue is currently a blocker for our full transition. That's why so many of my colleagues went to upvote it!

@jakebailey Yes, I actually shared the link in our internal company chat. We are working on a large project with a lot of developers, and our team really wants to migrate to tsgo. However, this specific issue is currently a blocker for our full transition. That's why so many of my colleagues went to upvote it!

[jakebailey]

How did you determine this cause? Did you determine this by making the change you're suggesting?

• readSema blocks goroutines (and their OS threads)

That isn't how the Go scheduler works; these goroutines would be waiting, yes, but not scheduled on any threads. The only reason Go would make more threads than GOMAXPROCS is if we were doing blocking IO concurrently, which this exact code helps limit.

I'm sure we could bound this, but I don't think this explanation makes sense.

[vetptzru]

@jakebailey You're right — waiting on the readSema channel does not hold an OS thread. I was wrong about that, thanks for the correction.

After looking at the code more carefully, I think the thread exhaustion might be coming from a different path — please correct me if I'm wrong.

parallelWorkGroup.Queue() (workgroup.go:39) spawns goroutines without an upper bound. Each goroutine performs module resolution (internal/module/resolver.go) which, as far as I can tell, makes many FileExists() / DirectoryExists() calls (os.Stat syscalls) that are not protected by readSema or any other semaphore.

On a native filesystem this wouldn't matter — stat(2) returns in microseconds and threads get recycled quickly. But on macFUSE, every syscall goes through user-space IPC (~1–10ms vs ~10µs), so each goroutine would
hold its OS thread much longer. If I understand correctly, with ~56,000 files and many imports each triggering multiple stat calls during resolution, the number of concurrent blocking syscalls could exceed Go's
default 10,000 thread limit.

It seems to me that readSema correctly bounds ReadFile, but the more numerous FileExists / DirectoryExists calls in module resolution might be the ones actually causing the problem on slow filesystems. But I
could be misreading the code — happy to be corrected.

[jakebailey]

But on macFUSE, every syscall goes through user-space IPC (~1–10ms vs ~10µs), so each goroutine would
hold its OS thread much longer. If I understand correctly, with ~56,000 files and many imports each triggering multiple stat calls during resolution, the number of concurrent blocking syscalls could exceed Go's
default 10,000 thread limit.

I suppose if the Go runtime is treating these as blocking calls (not going through the "netpoller"), and then spawning new threads to make progress in the meantime, this could happen.

Would you mind trying #3369 and see if this improves your situation?

[vetptzru]

@jakebailey I checked out your branch, built the binary, and tested it against our project on the macFUSE volume.

I'm happy to report that the fix works perfectly! The process completes successfully without any crashes. I monitored the process during execution, and the OS thread count never exceeds 26 now, which is a massive improvement compared to the 9,000+ we were seeing before.

Thank you so much for providing this fix! My team really appreciates it, as this completely unblocks our migration.

[jakebailey]

I'm not sure if that's going to be the fix, as it very much hurts everyone else's perf.