5 ms·

Would the Windows-equivalent of fork() be CreateProcess() ?

pjmlp 9y ago
No, because the semantics aren't the same. CreateProcess() is like posix_spawn(), or if you prefer fork()/exec(). Windows is a thread based OS, not process based, hence why the focus on thread performance, not on process creation.
- zokier 9y ago
  > Windows is a thread based OS, not process based, hence why the focus on thread performance, not on process creation. Which, somewhat ironically, leads NT to have worse numbers in the create thread test than linux in the create process one (25.6us vs 18us). The redeeming factor of NT is their async IO model which afaik is the best among mainstream OS.
  - udp 9y ago
    IOCP is very complicated to code against, though. kqueue can do nearly all the same things and is both much cleaner and more portable.
    - trentnelson 9y ago
      It's a very different paradigm to wrap your head around, but once you grok the NT kernel's approach to I/O (packet based IRPs, inherently asynchronous, thread-agnostic), and thread scheduling, I/O completion ports are very powerful constructs. The key difference is that I/O completion ports can be used to achieve asynchronous I/O on any underlying object, e.g. files and sockets, and they have this nifty built-in concept of concurrency, such that the kernel can ensure there is always one running thread per CPU core (which is optimal from a scheduling perspective). You can't use file descriptors with epoll/kqueue, and you certainly can't say "ensure every core only has one active thread running". "The key to understanding what makes asynchronous I/O in Windows special is...": https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=54 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... "Thread-agnostic I/O with IOCP": https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=62 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...
- arghwhat 9y ago
  There is no such thing as a "thread based OS". The statement simply doesn't make sense. The concepts of processes and threads work just the same in Linux and Windows (and internally just map to the execution unit of the scheduler, together with resource mappings and privileges), and user-space expectations are similar for the two. The main difference is that fork() is not available on Windows, but fork() is a terrible idea anyway. Fast spawn of processes isn't used for performance critical things on either OS, as process spawning is considered slow on Linux and entirely useless on Windows. Fast spawn of threads is also generally avoided, as even that is usually considered too slow. Windows is slow at creating processes (and most other things involving the kernel) not because of differences in OS use-case, but simply due to performance apparently not being a priority for Microsoft.
  - pjmlp 9y ago
    Then you should spend some time educating yourself about such OSes, like Windows. A thread based OS is an OS where threads are the core unit of execution, and processes are just a kind of execution capsule with one thread executing by default. The kernel scheduler only understands threads. This by opposition to process based OSes like UNIX, where there is a clear distinction between a process and thread execution. The kernel scheduler handles processes and threads separately. In many UNIX platforms, a process that doesn't perform any thread related API call, won't have any thread running on its context. This was quite clear during the days when UNIX systems where still researching how to adapt threads into the process execution model. And in many cases the impedance mismatch is still visible in modern UNIX systems, like for example what happens to any given thread when a signal is triggered, or to the whole process when a thread decides to fork. You can start by getting yourself a copy of "Windows Internals" book. Here is an old version of "Processes, Threads, and Jobs in the Windows" chapter in the 5th edition. https://www.microsoftpressstore.com/articles/printerfriendly/2233328 https://www.microsoftpressstore.com/articles/printerfriendly...
    - noselasd 9y ago
      Note that in linux, threads are the unit of scheduling, not processes.

No, because the semantics aren't the same. CreateProcess() is like posix_spawn(), or if you prefer fork()/exec(). Windows is a thread based OS, not process based, hence why the focus on thread performance, not on process creation.

zokier 9y ago
> Windows is a thread based OS, not process based, hence why the focus on thread performance, not on process creation. Which, somewhat ironically, leads NT to have worse numbers in the create thread test than linux in the create process one (25.6us vs 18us). The redeeming factor of NT is their async IO model which afaik is the best among mainstream OS.
- udp 9y ago
  IOCP is very complicated to code against, though. kqueue can do nearly all the same things and is both much cleaner and more portable.
  - trentnelson 9y ago
    It's a very different paradigm to wrap your head around, but once you grok the NT kernel's approach to I/O (packet based IRPs, inherently asynchronous, thread-agnostic), and thread scheduling, I/O completion ports are very powerful constructs. The key difference is that I/O completion ports can be used to achieve asynchronous I/O on any underlying object, e.g. files and sockets, and they have this nifty built-in concept of concurrency, such that the kernel can ensure there is always one running thread per CPU core (which is optimal from a scheduling perspective). You can't use file descriptors with epoll/kqueue, and you certainly can't say "ensure every core only has one active thread running". "The key to understanding what makes asynchronous I/O in Windows special is...": https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=54 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-... "Thread-agnostic I/O with IOCP": https://speakerdeck.com/trent/pyparallel-how-we-removed-the-gil-and-exploited-all-cores?slide=62 https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...
arghwhat 9y ago
There is no such thing as a "thread based OS". The statement simply doesn't make sense. The concepts of processes and threads work just the same in Linux and Windows (and internally just map to the execution unit of the scheduler, together with resource mappings and privileges), and user-space expectations are similar for the two. The main difference is that fork() is not available on Windows, but fork() is a terrible idea anyway. Fast spawn of processes isn't used for performance critical things on either OS, as process spawning is considered slow on Linux and entirely useless on Windows. Fast spawn of threads is also generally avoided, as even that is usually considered too slow. Windows is slow at creating processes (and most other things involving the kernel) not because of differences in OS use-case, but simply due to performance apparently not being a priority for Microsoft.
- pjmlp 9y ago
  Then you should spend some time educating yourself about such OSes, like Windows. A thread based OS is an OS where threads are the core unit of execution, and processes are just a kind of execution capsule with one thread executing by default. The kernel scheduler only understands threads. This by opposition to process based OSes like UNIX, where there is a clear distinction between a process and thread execution. The kernel scheduler handles processes and threads separately. In many UNIX platforms, a process that doesn't perform any thread related API call, won't have any thread running on its context. This was quite clear during the days when UNIX systems where still researching how to adapt threads into the process execution model. And in many cases the impedance mismatch is still visible in modern UNIX systems, like for example what happens to any given thread when a signal is triggered, or to the whole process when a thread decides to fork. You can start by getting yourself a copy of "Windows Internals" book. Here is an old version of "Processes, Threads, and Jobs in the Windows" chapter in the 5th edition. https://www.microsoftpressstore.com/articles/printerfriendly/2233328 https://www.microsoftpressstore.com/articles/printerfriendly...
  - noselasd 9y ago
    Note that in linux, threads are the unit of scheduling, not processes.