4 ms·

Win32 _is_ hilariously complicated(albeit as powerful as anything else with perhaps more steps upfront). Consider creating a child process in GNU/Linux: fork(

Win32 _is_ hilariously complicated(albeit as powerful as anything else with perhaps more steps upfront). Consider creating a child process in GNU/Linux: fork(); Vs in win32’s asinine API: CreateProcess( NULL, // No module name (use command line) argv[1], // Command line NULL, // Process handle not inheritable NULL, // Thread handle not inheritable FALSE, // Set handle inheritance to FALSE 0, // No creation flags NULL, // Use parent's environment block NULL, // Use parent's starting directory &si, // Pointer to STARTUPINFO structure &pi ) // Pointer to PROCESS_INFORMATION structure )

hexomancer 4y ago
It's funny that you chose fork to make your point because in my opinion window's version is vastly superior. First of all the name CreateProcess is obviously much more readable than fork. When I want to create a process, I usually want to run some function in the new thread which the windows version takes as arguments, alternatively fork copies the entire god damn process (what?) and I have to choose what to do based on the return value. The only reason the performance of fork is not abysmal is because the underlying operating system has to implement some sort of copy on write optimization but that just makes the performance characteristics of the program less transparent.
robocat 4y ago
fork() looks zen, but causes fiendish complications. Microsoft Research wrote a well referenced rebuttal to your opinion (2019): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... A few of the points made: * Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state. The POSIX specification now lists 25 special cases in how the parent’s state is copied to the child [63]: file locks, timers, asynchronous IO operations, tracing, etc. In addition, numerous system call flags control fork’s behaviour with respect to memory mappings (Linux madvise() flags MADV_DONTFORK/DOFORK/WIPEONFORK, etc.), file descriptors (O_CLOEXEC, FD_CLOEXEC) and threads (pthread_atfork()). Any non-trivial OS facility must document its behaviour across a fork, and user-mode libraries must be prepared for their state to be forked at any time. The simplicity and orthogonality of fork is now a myth. * Fork doesn’t compose * Fork isn’t thread-safe * Fork is insecure * Fork is slow * Fork doesn’t scale Etcetera e.g. O_CLOEXEC, FD_CLOEXEC, EFD_CLOEXEC, EPOLL_CLOEXEC, F_DUPFD_CLOEXEC, IN_CLOEXEC, MFD_CLOEXEC, SFD_CLOEXEC, SOCK_CLOEXEC, TFD_CLOEXEC, DRM_CLOEXEC, FAN_CLOEXEC, UDMABUF_FLAGS_CLOEXEC Edit: Good discussion both pro and against the paper here: https://lwn.net/Articles/785430/ https://lwn.net/Articles/785430/

hexomancer 4y ago

It's funny that you chose fork to make your point because in my opinion window's version is vastly superior. First of all the name CreateProcess is obviously much more readable than fork. When I want to create a process, I usually want to run some function in the new thread which the windows version takes as arguments, alternatively fork copies the entire god damn process (what?) and I have to choose what to do based on the return value. The only reason the performance of fork is not abysmal is because the underlying operating system has to implement some sort of copy on write optimization but that just makes the performance characteristics of the program less transparent.

robocat 4y ago

fork() looks zen, but causes fiendish complications. Microsoft Research wrote a well referenced rebuttal to your opinion (2019): https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf https://www.microsoft.com/en-us/research/uploads/prod/2019/0... A few of the points made: * Fork is no longer simple. Fork’s semantics have infected the design of each new API that creates process state. The POSIX specification now lists 25 special cases in how the parent’s state is copied to the child [63]: file locks, timers, asynchronous IO operations, tracing, etc. In addition, numerous system call flags control fork’s behaviour with respect to memory mappings (Linux madvise() flags MADV_DONTFORK/DOFORK/WIPEONFORK, etc.), file descriptors (O_CLOEXEC, FD_CLOEXEC) and threads (pthread_atfork()). Any non-trivial OS facility must document its behaviour across a fork, and user-mode libraries must be prepared for their state to be forked at any time. The simplicity and orthogonality of fork is now a myth. * Fork doesn’t compose * Fork isn’t thread-safe * Fork is insecure * Fork is slow * Fork doesn’t scale Etcetera e.g. O_CLOEXEC, FD_CLOEXEC, EFD_CLOEXEC, EPOLL_CLOEXEC, F_DUPFD_CLOEXEC, IN_CLOEXEC, MFD_CLOEXEC, SFD_CLOEXEC, SOCK_CLOEXEC, TFD_CLOEXEC, DRM_CLOEXEC, FAN_CLOEXEC, UDMABUF_FLAGS_CLOEXEC Edit: Good discussion both pro and against the paper here: https://lwn.net/Articles/785430/ https://lwn.net/Articles/785430/