buffer more reads from a boot-file file descriptor

[mflatt]

Before:

$ echo "(exit)" | strace -c scheme -q
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 98.87    0.008833           1      4626           read
  0.87    0.000078           1        68           mmap
  0.22    0.000020           2         8           rt_sigaction
  0.03    0.000003           0         6           close
  0.00    0.000000           0         5           mprotect
....

After:

$ echo "(exit)" | strace -c scheme -q
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 68.42    0.001443          51        28           munmap
 24.56    0.000518           3       150           read
  5.17    0.000109           1        68           mmap
  0.95    0.000020           2         8           newfstatat
....

The overall difference in startup time turns out to be very small on Linux and macOS — just a a couple of milliseconds, if anything. But buffering is generally a good idea, and the change makes a startup system-call trace look less suspicious. (See, for example, the discussion in #263.)

I tried this kind of change a couple of times before over the years, but the result always seemed like too much for little benefit. This time, I found a path that involves fewer changes, involves simpler local changes that are easier to check through a diff, and tends to make the code nicer (collapsing two uptr decodings into one) instead of more complicated; so, I think it's worthwhile.

In addition to buffering changes, this commit adds Sregister_boot_file_bytes, so that an embedding application can point to bytes that are already loaded into memory. I experimented with that by linking a program with -sectcreate on macOS and using getsectiondata to find embedded boot files at run time. It doesn't make startup any faster, but that kind of approach might be useful for tools that create a single-file executable including boot files.

[burgerrg]

The Sregister_boot_file_bytes procedure will be useful. I did something similar in the past in Windows to read the boot file from an embedded resource file.

[LiberalArtist]

In addition to buffering changes, this commit adds Sregister_boot_file_bytes, so that an embedding application can point to bytes that are already loaded into memory. I experimented with that by linking a program with -sectcreate on macOS and using getsectiondata to find embedded boot files at run time. It doesn't make startup any faster, but that kind of approach might be useful for tools that create a single-file executable including boot files.

Tangentially, the C23 standard added an #embed preprocessor directive to efficiently and portably embed binary data into programs. It seems like it might be a useful approach to boot files when a sufficiently recent C compiler is available.