I think the title would benefit from mentioning that this is for cosmopolitan libc. I was expecting this to be about syscall portability in general.

Obviously, do whatever you want if you’re just playing around, but please do be aware that the syscall interface on macOS is private, subject to change at any time, and should never be used directly.

The coverage and the attention to detail here is incredible. Hats off to Justine.

I would love to know how this table is generated and what the test process is. What's the best way to run tests like this across such a wide variety of OSes? Maybe vagrant images?

Not long ago golang switched from doing direct system calls to libc on *BSD systems. The explanation I believe was that the BSD systems fix a lot of kernel problems and compatibility issues in libc and it was just easier to use libc then try to rewrite all of that in the golang standard libraries. On Linux it uses direct system calls for everything.

Most of the cell labels are self-explanatory, but some of them are a bit puzzling (as is the intended ordering) and a bit amusing: "hairy"? "no cow"?

Could not find what Metal is (bare-metal?). Can anyone explain it or point out to a relevant docs page?

In case the author is reading these comments MalwareBytes blocks justine.lol as riskware for some reason.

I’m not an expert but I was under the impression these we’re library calls on macOS, and the system calls were unstable and not supposed to be used directly?

one of the most cringe things I'll see in "high performance" code is ad hoc syscalls in the middle of loops and such. it should be much more obvious imo in environments like python notebooks that these less scalable operations are happening

What is the "metal" platform listed in the rightmost column? Also what does "zipos" mean, in some of its cells?

Incredible output like this is why Justine is my proudest developer sponsorship https://github.com/sponsors/jart

When they say metal here, what does that actually mean?

I used to work with someone who was an expert in writing cryptography libraries. He insisted on never using any system calls for maximum portability (he also wrote his own memory allocators and optimized for small binary size). Seemed quirky to me but he was proven right multiple times as our ultraportable library let us book some big deals that would have been otherwise infeasible without a big rewrite

Some of the Win32 things mention "millisecond precision only", but this isn't quite correct.

Waitable Timers on Win32 let you request time values in units of 200 nanoseconds. See `CreateWaitableTimer`, and `SetWaitableTimer`.

`Sleep` and `SleepEx` can be implemented using a waitable timer, just use `WaitForSingleObjectEx`.

If you need to wait for an object (semaphore, etc) using a time unit other than milliseconds, you can use `WaitForMultipleObjectsEx` with one of them being a waitable timer.

---

The next question is if Win32 can actually deliver those requests for precise times or not. From the testing I did a while ago where I was simulating Sleep, I got actual sleep times rounded to about 4ms. So much for requesting nanosecond level precision.