> What this crate is doing is not particularly out of the ordinary.
"Out of the ordinary" and "good" are different qualifiers: patching a runtime initialization table might be ordinary (and even acceptable) in a leaf executable where the dependencies are carefully checked for conflicting initialization behavior, but it's pretty dangerous in a library (or crate) that might get mixed into all kinds of executables with different initialization expectations.
> This is pretty much what this is doing.
It's close, but you're relying on much racier and flimsier primitives. The trick that I'm most familiar with in Win32 applications is to create a named pipe or other IPC mechanism to communicate over, since the failure modes there are much better defined (and not subject to race conditions).
> patching a runtime initialization table might be ordinary (and even acceptable) in a leaf executable where the dependencies are carefully checked for conflicting initialization behavior, but it's pretty dangerous in a library (or crate) that might get mixed into all kinds of executables with different initialization expectations.
I'm not sure why that would be the case. Any C++ static constructor ends up in that table. Any Rust crate using #[ctor] ends up in there.
> It's close, but you're relying on much racier and flimsier primitives. The trick that I'm most familiar with in Win32 applications is to create a named pipe or other IPC mechanism to communicate over, since the failure modes there are much better defined (and not subject to race conditions).
As opposed to WaitSingleObject? Or what exactly are you objecting to here exactly? I'm also not sure which race condition you are referring to in particular. The main race this has (or any other library that does something similar) is that it needs a utility process to spawn to inherit the handle of the copy gc process. No named pipe will resolve this.
"Out of the ordinary" and "good" are different qualifiers: patching a runtime initialization table might be ordinary (and even acceptable) in a leaf executable where the dependencies are carefully checked for conflicting initialization behavior, but it's pretty dangerous in a library (or crate) that might get mixed into all kinds of executables with different initialization expectations.
> This is pretty much what this is doing.
It's close, but you're relying on much racier and flimsier primitives. The trick that I'm most familiar with in Win32 applications is to create a named pipe or other IPC mechanism to communicate over, since the failure modes there are much better defined (and not subject to race conditions).