Comment by pjmlp
1 day ago
True, but on Windows the approach is then to use COM servers, which have a faster IPC model, and can even serve multiple clients, depending on how the appartement space is configured.
1 day ago
True, but on Windows the approach is then to use COM servers, which have a faster IPC model, and can even serve multiple clients, depending on how the appartement space is configured.
"Faster IPC model" than what? Faster than writing to and reading from a pipe? Faster than POSIX shared memory?
Than UNIX fork/exec model, or calling into Create Process all the time.
Windows has a more rich set of IPC stuff than POSIX, especially since it has a microkernel like design.
If you are going to say it is everything on the same memory space anyway, it isn't.
Optional on Windows 10, and enforced on Windows 11, Hyper-V is always running, and several components including kernel and driver modules are sandboxed into their little worlds.
Several additional sandboxing changes were announced at BUILD.
fork/exec is not an IPC model...
3 replies →
If you want the isolation features of a separate process, you can’t substitute it with a single multithreaded COM server process.
.NET tried this with app domains, which are now deprecated.
App Domains were in process, which isn't was I am talking about with outproc COM.
Also App Domains are partially back in .NET Core, isolation features aren't there, but code unloading is, via AssemblyLoadContext.
My point is that “just write a COM server” is not an answer to the problem of “I want each work item to be segregated from each other.”