Function trace logs will report stack usage accurately. It won't include
the argv/environ block. Our clone() polyfill is now simpler and does not
use as much stack memory. Function call tracing on x86 is now faster too
This change doubles the performance of thread spawning. That's thanks to
our new stack manager, which allows us to avoid zeroing stacks. It gives
us 15µs spawns rather than 30µs spawns on Linux. Also, pthread_exit() is
faster now, since it doesn't need to acquire the pthread GIL. On NetBSD,
that helps us avoid allocating too many semaphores. Even if that happens
we're now able to survive semaphores running out and even memory running
out, when allocating *NSYNC waiter objects. I found a lot more rare bugs
in the POSIX threads runtime that could cause things to crash, if you've
got dozens of threads all spawning and joining dozens of threads. I want
cosmo to be world class production worthy for 2025 so happy holidays all
At least in neovim, `│vi:` is not recognized as a modeline because it
has no preceding whitespace. After fixing this, opening a file yields
an error because `net` is not an option. (`noet`, however, is.)
- On Windows connect() can now be interrupted by a signal; connect() w/
O_NONBLOCK will now raise EINPROGRESS; and connect() with SO_SNDTIMEO
will raise ETIMEDOUT after the interval has elapsed.
- We now get the AcceptEx(), ConnectEx(), and TransmitFile() functions
from the WIN32 API the officially blessed way, using WSAIoctl().
- Do nothing on Windows when fsync() is called on a directory handle.
This was raising EACCES earlier becaues GENERIC_WRITE is required on
the handle. It's possible to FlushFileBuffers() a directory handle if
it's opened with write access but MSDN doesn't document what it does.
If you have any idea, please let us know!
- Prefer manual reset event objects for read() and write() on Windows.
- Do some code cleanup on our dlmalloc customizations.
- Fix errno type error in Windows blocking routines.
- Make the futex polyfill simpler and faster.
Thanks to @autumnjolitz (in #876) the Cosmopolitan codebase is now
acquainted with Apple's outstanding ulock system calls which offer
something much closer to futexes than Grand Central Dispatch which
wasn't quite as good, since its wait function can't be interrupted
by signals (therefore necessitating a busy loop) and it also needs
semaphore objects to be created and freed. Even though ulock is an
internal Apple API, strictly speaking, the benefits of futexes are
so great that it's worth the risk for now especially since we have
the GCD implementation still as a quick escape hatch if it changes
Here's why this change is important for x86 XNU users. Cosmo has a
suboptimal polyfill when the operating system doesn't offer an API
that let's us implement futexes properly. Sadly we had to use that
on X86 XNU until now. The polyfill works using clock_nanosleep, to
poll the futex in a busy loop with exponential backoff. On XNU x86
clock_nanosleep suffers from us not being able to use a fast clock
gettime implementation, which had a compounding effect that's made
the polyfill function even more poorly. On X86 XNU we also need to
polyfill sched_yield() using select(), which made things even more
troublesome. Now that we have futexes we don't have any busy loops
anymore for both condition variables and thread joining so optimal
performance is attained. To demonstrate, consider these benchmarks
Before:
$ ./lockscale_test.com -b
consumed 38.8377 seconds real time and
0.087131 seconds cpu time
After:
$ ./lockscale_test.com -b
consumed 0.007955 seconds real time and
0.011515 seconds cpu time
Fixes#876
