Re: 32 bits time_t and Y2038 issue

On 19/03/2025 15:27, Grant Edwards wrote:

On 2025-03-19, David Brown <david.brown@hesbynett.no> wrote:
 

There are certainly a few things that Cygwin can handle that msys2
cannot.  For example, cygwin provides the "fork" system call that is
very slow and expensive on Windows, but fundamental to old *nix
software.

 I believe Windows inherited that from VAX/VMS via Dave Cutler.

I am always a bit wary of people saying features were copied from VMS into Windows NT, simply because the same person was a major part of the development.  Windows NT was the descendent of DOS-based Windows, which in turn was the descendent of DOS.  These previous systems had nothing remotely like "fork", but Windows already had multi-threading.  When you have decent thread support, the use of "fork" is much lower - equally, in the *nix world at the time, the use-case for threading was much lower because they had good "fork" support.  Thus Windows NT did not get "fork" because it was not worth the effort - making existing thread support better was a lot more important.

 Back when the Earth was young I used to do embedded development on
VMS. I was, however, a "Unix guy" so my usual work environment on VMS
was "DEC/Shell" which was a v7 Bourne shell and surprisingly complete
set of v7 command line utilities that ran on VMS. [Without DEC/Shell,
I'm pretty sure I wouldn't have survived that project.] At one point I
wrote some fairly complex shell/awk/grep scripts to analyze and
cross-reference requirements documents written in LaTeX.  The scripts
would have taken a few minutes to run under v7 on an LSI-11, but they
took hours on a VAX 780 under VMS DEC/Shell (and used up ridiculous
amounts of CPU time). I was baffled.  I eventually tracked it down to
the overhead of "fork". A fork on Unix is a trivial operation, and
when running a shell program it happens a _lot_.

Yes, fork is relatively trivial (in terms of execution time and resources) on /most/ *nix systems.  (On some, like ucLinux without an MMU, it is very expensive.)  Basically, it is handled by making all read-write pages of the process read-only, duplicating the process structure, and then handling copying of what were writeable pages if and when the parent or child actually write to them.  This has become more costly as applications get more advanced and have more memory pages than they used to, but is still relatively cheap.
However, true "fork" is very rarely useful, and is now rarely used in modern *nix programming.  Most uses of "fork" are either followed immediately by an exec call to load and run a new executable (so vfork/execve is much cheaper), or they are duplicates of a server daemon and you can usually do the job more efficiently with multi-threading or asynchronous handling.  It is typically only for servers that want to spawn duplicates that have isolation for security reasons (such as an ssh server) where it is worth using "fork".
So these days, bash does not use "fork" for starting all the subprocesses - it uses vfork() / execve(), making it more efficient and also conveniently more amenable to running on Windows.

 On VMS, a fork() call in a C program had _huge_ overhead compared to
Unix [but dog bless the guys in Massachusetts, it worked]. I'm not
sure if it was the process creation itself, or the "duplication" of
the parent that took so long. Maybe both. In the end it didn't matter:
it was so much easier to do stuff under DEC/Shell than it was under
DCL that we just ran the analysis scripts overnight.
 

On Windows with Cygwin, "fork" needs to copy all the writeable pages (and perhaps also non-writeable pages), as well as explicitly duplicate things like file handles.  There is also a measurable overhead for processes even if they don't fork - for many types of resource allocation (such as file and network handles), the Cygwin layer has to track the resources just in case you fork later on.  msys and msys2 don't support fork(), so their POSIX emulation layer is much thinner - in many cases it just translates POSIX-style calls into the Windows equivalent.
(For a more entertaining use of the term "fork", I recommend the Netflix series "The Good Place".)