Hacker News Reader

Comment by pjmlp | Hacker News Reader

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.

View on HN

"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...

It actually kind of is, hence why you have information about parent/child and get to share memory.

This is how a http server back in the day would share the request context for the child process to reply back.

I would say that pipes and shared memory are the IPC mechanisms? Controlling the state of the exec'd process's file descriptors would counts as a way to set up interprocess communication, but once that's done, it's the pipe or SHM that does the actual communication.

The problem with POSIX IPC is that passing file descriptors between processes (other than parent passing to child via fork) is hard. Yes, SCM_RIGHTS can do it, but it is quite error prone and rarely done.

Every single Wayland and GPU-accelerated X11 app does that all the time.

That's like comparing apples and oranges. When tooling is tied to a platform, you're adding in the entire platform to the comparison.

Mozilla implemented an alternative to COM, called XPCOM. XP here means cross platform. Perhaps you could compare against that to take the platform out of the equation.

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.”

A one-shot process is easier to build and reason about than an event-driven server (speaking as someone who has written plenty of both).

Reply on news.ycombinator.com