4 ms·
I have the entirely opposite opinion. IMO a big mistake of the UNIXy model is that so much state is preserved across the creation of a process. For example, th
by amluto 4mo ago
I have the entirely opposite opinion. IMO a big mistake of the UNIXy model is that so much state is preserved across the creation of a process. For example, there are APIs to have a specific thing be fd number 4 so you can run a program and have it find that thing at fd 4. This is weird.
Windows, for all its many, many faults, did not use fork+exec and instead mostly has options for how one creates a process. It wasn’t done elegantly, but it was the right decision.
- 1718627440 4mo agoIs it weirder, that you can pass an variable precisely into argument 4? You do need to pass information to a subprocess and there needs to be some agreement on what means what. Sure, maybe you could use names instead of fds, but that sounds needlessly complicated.
- jonhohle 4mo agoThat’s like saying you could use positions to specify function argument access (as in assembly) instead of variable names. File descriptors being numbers that are likely array indexes in a file handle seems like a leaky abstraction. Having a namespace that a parent process share with its children seems like a much cleaner design.
- amluto 4mo agoA way to pass a defined list of handles to a subprocess (or a friendly other process) makes sense. Having that mechanism be direct inheritance of those handles with the same numbering as the source is obnoxious.
- burnt-resistor 4mo agoYou're simply failing to grasp the value of the simplicity, compatibility, and portability of POSIX/*nix. Inventing yet another way to create a process would be complex and break things. It's a-la-carte to enable configuration after fork of the new CoW or non-CoW process but before exec (unless vfork or similar were used). This is the model. If you want to greenfield re-engineer the world with all new system calls and a totally different execution model, feel free to go right ahead.
- wvenable 4mo ago"The reasonable man adapts himself to POSIX: the unreasonable one persists in trying to adapt the POSIX to himself. Therefore all progress depends on the unreasonable man." ― George Bernard Shaw, probably.
- __david__ 4mo agoHaving fd 4 mean something specific is no weirder than having fds 0,1, and 2 mean something specific, which is probably never going to change. At some point you just gotta embrace the Unix.
- JdeBP 4mo agoHeh! The Unix didn't embrace the idea of file descriptor 3 meaning something specific. (-: * https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html https://jdebp.uk/FGA/bernstein-on-ttys/cttys.html Interestingly, on MS/PC/DR-DOS file descriptor 3 was stdaux. and file descriptor 4 was stdprn.
- chasil 4mo agoWell, Cygwin and Busybox have shown me that fork-heavy activities are about 100x slower on Windows than Linux. The Windows approach may be correct, but it suffers in performance from the POSIX perspective. I have heard that WSL1 iimproves this.
- amluto 4mo agoLinux has worked pretty hard to optimize fork(). This doesn’t mean that fork() is a good idea. Windows does not historically depend on fork(), so there was no native fork(), so Cygwin kludged it up.
- JdeBP 4mo agoActually, there is a native fork. There had to be, as POSIX personality support was a part of the Windows NT 3.1 design. What there wasn't was a Win32 form of fork. The Native API for Windows NT allowed it quite straightforwardly.
- jkrejcha 4mo agoIirc Cygwin used to use it but iirc they moved away from it because they said that it was pretty slow Though actually iirc werfault uses NtCreateUserProcess() to clone processes when writing out crash dumps to this day
- uecker 4mo agoWell, a lot of the power of the UNIX shell comes form this and I see this as a major advantage over Windows. So no, I do not think Windows got it right. Any kind of replacement should aim for the same conceptual simplicity and power. Sadly, I fear that people driving development nowadays are more interested in building unbreakable walled gardens for advertisement or app stores, or trying to squeeze down the some small gain when used on the cloud. I am more interested in general computing on the user side.
- dcrazy 4mo agoNothing about the UNIX shell is reliant on the fork model. Windows processes have stdio handles as well.
- uecker 4mo agoA lot of features of UNIX shells are build around pipe and dup and the fork + exec model. One can certainly implement in differently, but it is - like UNIX in general - very nice and elegant.
- amluto 4mo agoHelp me out here, please. Off the top of my head, the exec command is dependent on exec, except that a spawn + wait implementation would be a mostly okay substitute. Pipes and redirections don’t need fork + exec. Neither do subshells.
- uecker 4mo agoIf you use pipe() you get two ends in the same process, then you fork and child and parent can communicate. This is how a unix shell setups up pipes and it is rather elegant.
- dwattttt 4mo agoDoing the same thing on Windows, I create the pipe and get two ends in the same process. Then I'd call CreateProcess and indicate I want the pipe's handle (fd) inherited to the child, and I'd use a prearranged way to tell the child what the fd value is it should use. Possibly the most common way to tell the child the value is by setting it as a CLI arg in CreateProcess.