David Chisnall (*Now with 50% more sarcasm!*)4d ago

I know people like to make fun of niche operating systems, but for the five years I was at Microsoft I used Windows (10 then 11) as my daily driver. It’s much less stable than a professional OS, but it does kind-of work. I wouldn’t say it’s ready for the desktop. The UI is inconsistent and changes randomly between releases, a load of common software is basically useable only in a VM, it lags and freezes periodically (unlike an OS designed for interactive use, random drivers run a load of things directly in interrupt handlers, so you get latency spikes that you wouldn’t see in a more mainstream desktop OS) and the update process can hose the system, so it’s mostly of interest to people who like tinkering with their machines than people who actually want to get work done. Oh and a load of random bits of the OS have ads, but that’s what you get from a free ad-supported system instead of one developed by an active open-source community.

I don’t think I’d recommend anyone use it as their daily driver or in a work setting, but it’s not totally unusable. It’s not at the level of maturity than you’d expect from, say, Linux or FreeBSD, especially not for client workloads. If you do have to use it, I recommend that you install FreeBSD in a Hyper-V VM for real work. That’s what I did and it works quite well.

Show threadamy4d ago
@david_chisnall Drivers doing too much in interrupt handlers answers a lot of questions I had about windows..
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)4d ago

@amy I learned that accidentally. I was discussing how to adopt a security feature in NT and someone on that team casually mentioned third-party drivers (including antivirus) running things in interrupt handlers. The more I learned, the more horrified I was. On FreeBSD and XNU, interrupt handlers do one thing: wake a thread (or some work-queue equivalent). The thread is then preemptive. A small number of things run with interrupts disabled but it’s very rare in drivers or subsystems outside the very core parts of the OS. In Windows, the driver model seems to encourage people to just do the real work in interrupt handlers. So your USB camera is stalling a core (and whatever thread is currently trying to run there) for ms at a time, and so are a load of other kernel things.

Even FreeRTOS discourages this kind of thing, and it’s designed for a use case where it isn’t a terrible idea.

In CHERIoT RTOS we formalise it and bind interrupts to futexes, so the only thing that happens in an interrupt handler is that one or more futexes get woken and then we may make a scheduling decision if any of the woken threads are higher priority than the one that woke (on our chips, we have designed the interrupt controller so that it can avoid raising an interrupt if it wouldn’t result in a scheduling decision).

Show threadamy
@david_chisnall That's fascinating! It is just a consequence of API design making it difficult to pass work off into a another tread or are the interrupt handlers actually more capable in some way?
Apr 27 at 2:55amWeb
Show threadDavid Chisnall (*Now with 50% more sarcasm!*)3d ago

@amy I think it’s still possible to do the right thing, but no one has actively discouraged driver vendors from doing it. Most other systems have a trivial API that is some variant of ‘wake this work queue when this interrupt fires’. Windows may have such a thing (it has a lot of kernel APIs) but it doesn’t seem to be the one that fires.

I suspect it’s also an artefact of the fact that the vast majority of device drivers on Windows are third-party. Other systems went through a process of dramatically limiting the stuff that ran in ISRs around the time they did SMP support, because holding a lock while interrupted causes scalability problems when the interrupt doesn’t finish quickly. If MS did this, it wouldn’t make a difference because most of the things that hook interrupt handlers are third-party drivers. And if they don’t start doing it, the example drivers don’t get updated, so the new third-party drivers do the same thing, and so on.

Show threadRichard Barrell3d ago
@david_chisnall this reminds me of a thing I find really cute: FreeBSD still has (last time I checked) the giant kernel lock, but it's just been removed from every single subsystem that matters for performance, one at a time.