Possibly an unpopular opinion on this forum, but virtual memory has always been one of the strengths of the NT kernel. (And integration between the cache manager, virtual memory manager, file system (NTFS), overlapped I/O, completion ports, and threading. It’s a very robust and performant foundation when leveraged correctly.)
Not ssh related but I regularly suspend my terminal with Ctrl-S by accident, usually when going for Ctrl-C/V.
That was a nightmare to triage back in the late 90s when I did it. Thankfully Ctrl-Q (I think it’s Q) “resumes”, so, easy fix if you know what you’ve done.
WaitForMultipleObjects is fascinating behind the scenes. A single thread can wait on up to 64 independent events, which is done by plumbing the KTHREAD data structure with literally 64 slots for dispatcher header stuff, plus all the supporting Ke/dispatcher logic in the kernel.
There’s never been a POSIX equivalent to this. It requires sophisticated kernel support and the exact same parity can’t be achieved in user space alone.
Linux native semaphores are enough. Linux has been able to be very performant without it. That feature seems like way too over engineered for little gains.
Reading the link provided by https://news.ycombinator.com/item?id=47511778, I believe "atomically acquire multiple objects". The link states they try to emulate it by performing a poll then a read, but the gap between those results in a race, which is a terrible thing to have in a synchronisation primitive.
There was also something about needing to back out if any of the reads fails to acquire, which also sounds nasty.
Ah, interesting, so wfm does both the wait and the acquire!
When using eventfd it is indeed annoying having to both poll and later read to disarm the object (there are epoll tricks that can be used but are not generalizable).
The signal+wait is also a primitive that it is hard to implement atomically on posix.
When the PDIMMs were used with an appropriate file system + kernel, it was pretty cool. NTFS + DAX + kernel support yielded a file system where mmap’ing didn’t page fault. No page faults because the file content is already there, instantly.
So if you had mmap heavy read/write workloads… you could do some pretty cool stuff.
If you’ve got an existing paragraph written that you just know could be rephrased more eloquently, and can describe the type of rephrasing/restructuring you want… LLMs absolutely slap at that.
I finished this article in February this year, just before joining NVIDIA. It didn't get officially published then for... reasons. Posting now despite some of the information being a little out of date as I still think the content might be useful to others.
Tried to make the article as readable as possible on mobile, tablet, and desktop. Mobile necessitated a smaller font size for the code to obviate the need for horizontal scrolling.
Light/dark mode is supported, and the images are even cognizant of the selected mode!
I am doing a talk at PyData Seattle this year (Nov 7-9) focused on this topic, so any feedback regarding additional areas of interest would be appreciated.
Looks like ‘97. Unfortunately I can’t find the receipts! If I had to guess, I think I’d say somewhere around $2000 in all. That computer lasted me a LONG time. When it was done being a desktop, it became a Linux server until I sold it around 2009. Sometimes I wish I’d kept it: the Pentium 2 was such an important CPU and I smile every time I see the one on display in the Computer History Museum.