* Or can do but would be horrifying, like trying to run a compiled binary by mmaping it into your address space.
It's the "Windows way". Windows process creation is slow. No, they're not identical, they're different approaches to the problem.
> subprocesses it's likely specifically because it's something you can't do in threads
I suppose the question would be, "what can't you do, if you did it the Windows way?"
That said multiple threads are not multiple processes:
Using multiple threads means you get a single set of globals, and if any of them are contended you get a pile of sadness.
Similarly, tearing down threads is not necessarily sufficient to release all resources a library may have consumed because again: globals.
Related to globals: I’m not sure how heavily TLS is restricted on windows, but I recall various arbitrary limits being annoying on windows back when I did dev work, and I recall some annoying stuff with TLS — but that was back in the days of needing to support XP, so maybe it’s less of an issue these days?
You also get security advantages by pushing things into multiple processes that you don’t get from multiple threads, though I don’t really think that that’s an issue in this particular context.
Not sure what your reference to TLS is about; any more specifics?
EDIT: Ugh was thinking SSL! Duh.
https://learn.microsoft.com/en-us/windows/win32/procthread/t...
> That goes for any OS though
100%. I was of course speaking in the context of this thread, but yes you probably wouldn't take a Windows-developed app and simply shift it to UN*X without some form of re-thought on the implementation.
...Unless it was a .NET app :-)