Reply to post: Re: At least it uses processes

Re: At least it uses processes

How that works in Windows with its crippled process model and no support for fork() or similar niceties

I'm not a particular fan of the Windows process model (though thread security tokens, for example, were arguably a good idea), and Windows processes are very heavy. As someone who routinely develops on both Windows and UNIXy platforms (and has worked on a variety of others), I often miss the relative elegance and performance of UNIX when I work with Windows.¹

However, since XP, Windows has made it relatively straightforward to schedule work in a pool of preexisting child processes using CreateRemoteThread(Ex), which is quite fast. So the worker processes can be started ahead of time (with the pool expanding and contracting as needed), amortizing the process startup cost.

There's an obvious security concern with CreateRemoteThread, compounded by Microsoft's braindead treatment of process-handle privileges - to watch for the termination of another process, for example, you need the same privilege as you'd need to invoke CreateRemoteThread on it, so there's no safe way to permit only the monitoring of another process. And its use obviously requires care. But as a fast IPC mechanism for related processes it can work pretty well.

¹Of course, in the days before demand paging and COW, UNIX fork() wasn't exactly ideal either.