ShellExecute can dispatch Windows events, which means that it needs to
be called in a way that's consistent with the environment expected by
event-handling callbacks.
Relevant to #3832
When a glib message is logged in an OS thread not created by Racket,
then the current-future and async-callback-queue thread-local
variables were not initialized. The failure mode tended to be an
unending and memory-consuming cycle of triggering an error while
attempting to report an error.
Although there was a test for proper handling of logging calls from
foreign threads, the test previously created the "foreign" thread with
`call-in-os-thread`, which is not foreign enough.
Related to #3832
That way, a mutex or conditional variable can be referenced by
something else that has a finalizer and that might use the mutex or
condition variable.
Closes#3842
Add `record-ptr-offset` so that rktboot can use that instead of
assuming an offest of 1.
Also, introduce `type-untyped` and use it instead of `typemod` when
the intent is to leave an address unchanged by tagging. That makes the
implementation a little clearer, and it reduces the code that would
have to be changed to modify the tagging discipline (e.g., to tag by
adding instead of subtracting from an address).
Previously, the `raco setup` step would use `--user` and
`--avoid-main` when the scope was not specifically `installation`.
Change it to instead use those when the scop is specifically `user`.
That makes additional scopes treated more like an installation scope
than a user scope, which is consistent with how `raco setup` treats
things (i.e., link paths that are in the search path).
Overall, it seems that the idea of just layering packages in extra
scopes does not work out, and the layering needs to be built in more
deeply. That's what recent improvements for layering do. But this
change at least makes `raco pkg` and `raco setup` more consistent.
Thanks to Nate Griswold for drawing out this issue.
Various "config.rktd" options are meant to support creating layers of
installation that builds existing layers. Configuration options also
supports a "tethering" mode that makes `raco setup` create launchers
that bind to the configration (so an environment variant doesn't have
to be set). While several pieces of this idea were in place in commit
6369e56709, it wasn't really finished, and there was no documentation
to explain how things are intended to work.
There's definitely still room for tools that automate the steps for
setting up a layer and tethering.
Along the way, this commit cleans up the `(find-system-path
'exec-file)` aspect of embedding executables as launchers to make them
consistent across platforms and work right as tethered launchers.
Clean up tangled and partly repeated code, and normalize ELF use for
boot files and embedded modules. Also, repair Unix-style Mac OS
builds.
With these changes, `raco exe` should always produce a well-formed
ELF, Mach-O, or PE excutable. The mode that just appends to the end of
the executable should happen only platforms that don't use one of
those three --- which are very rare and unlikely supported, anyway.
Closes#3831
- avoid blocking once we are committed to an error
- consume eof exactly when there is an error or eof is the only thing in the stream
Also to improve the testing of these two, the new test suite support
lets us carefully control what's coming out of the port, including
situations where there are eof objects with data that comes afterwards
(so we can test if an eof is consumed or not)
