TLS exhaustion

[Simn]

I had a bug in hxcoro which caused too many TLS instances to be allocated, which resulted in a straight up segfault on MacOS HL. This was pretty hard to spot even for Claude, but he ultimately fixed it and said:

macOS caps per-process pthread TLS keys at 512 (vs Linux's 1024), and HL never calls pthread_key_delete on GC. After ~170 test runs the keys were exhausted.

So at the very least this should fail more gracefully, but it also sounds like this is a general leak. I don't have a reproducible example because I don't have a mac, but a loop that just creates TLS instances should do it.

[Apprentice-Alchemist]

HL never calls pthread_key_delete on GC

This is wrong, HL does actually call pthread_key_delete:

hashlink/src/std/thread.c

Line 515 in 0ff5b47

pthread_key_delete(l->key);

That said, TLS slot exhaustion does sound like a reasonable theory, since the GC may not immediately free allocations and call finalizers.

[Simn]

Right, I suppose it assumed that the GC would run at some point, and then the only conclusion would be that the TLS are not freed. They should have become unreferenced in my original example so I wonder why this caused a problem.

Either way, something other than a segfault would be nice.