4 ms·

To be fair for Windows, you shouldn’t emulate fork() but rather spawn new threads, which Windows can do in less than a millisecond. This should give you much qu

To be fair for Windows, you shouldn’t emulate fork() but rather spawn new threads, which Windows can do in less than a millisecond. This should give you much quicker results, but comes with other complexities, especially for UN*X-ported apps. Given you emulated fork(), you probably know this.

Spivak 2y ago
But those aren't really the same? I mean yes they are both ways to acquire additional units of execution but if you're reaching for subprocesses it's likely specifically because it's something you can't do in threads*. * Or can do but would be horrifying, like trying to run a compiled binary by mmaping it into your address space.
- nullindividual 2y ago
  > But those aren't really the same? 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?"
  - olliej 2y ago
    I would agree, if you’re wanting to run your server software on windows, your software should be designed to work well with windows. That goes for any OS though - if you’re running a high volume server then you shouldn’t be throwing away perf by designing your software in a way that works badly on the host OS. 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.
    - nullindividual 2y ago
      For .NET Framework, AppDomains were a solution to isolation. .NET [Core] deprecated this feature, moving towards assembly loading contexts (and the, IMO, unfortunate move towards microservices -- like everyone needs them /s). 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/thread-local-storage 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 :-)
  - gpderetta 2y ago
    Address space separation.
  - amluto 2y ago
    Let’s give Windows some credit here. Windows had usable threads long before Linux.
    - nullindividual 2y ago
      NT works on threads, so yeah :-) It was _designed_ that way.

Spivak 2y ago

But those aren't really the same? I mean yes they are both ways to acquire additional units of execution but if you're reaching for subprocesses it's likely specifically because it's something you can't do in threads*. * Or can do but would be horrifying, like trying to run a compiled binary by mmaping it into your address space.

nullindividual 2y ago
> But those aren't really the same? 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?"
- olliej 2y ago
  I would agree, if you’re wanting to run your server software on windows, your software should be designed to work well with windows. That goes for any OS though - if you’re running a high volume server then you shouldn’t be throwing away perf by designing your software in a way that works badly on the host OS. 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.
  - nullindividual 2y ago
    For .NET Framework, AppDomains were a solution to isolation. .NET [Core] deprecated this feature, moving towards assembly loading contexts (and the, IMO, unfortunate move towards microservices -- like everyone needs them /s). 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/thread-local-storage 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 :-)
- gpderetta 2y ago
  Address space separation.
- amluto 2y ago
  Let’s give Windows some credit here. Windows had usable threads long before Linux.
  - nullindividual 2y ago
    NT works on threads, so yeah :-) It was _designed_ that way.