<div dir="auto"><div>Thanks, I guess I'll have to dig into the code to understand better. There must be a reason why OTP doesn't just fork early in the boot process to keep around another (or multiple other) child processes for the erl_child_setup use case. Maybe there is/was a platform where that is not an option. Once I get more time or when this gets urgent I'll revisit.</div><div dir="auto"><br></div><div dir="auto">Anyone knows about iPhone targets?<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com" target="_blank" rel="noreferrer">mikpelinux@gmail.com</a>> schrieb am Fr., 17. Sep. 2021, 14:03:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep 17, 2021 at 1:45 PM Dominic Letz <<a href="mailto:dominic@diode.io" rel="noreferrer noreferrer" target="_blank">dominic@diode.io</a>> wrote:<br>
> So this brings me to my question #1. Is there a way to remove the dependency on these external binaries of erl_child_setup [...]<br>
<br>
As I recall, erl_child_setup is there to avoid needing to fork()<br>
inside the Erlang VM (when spawning off external commands via e.g.<br>
os:cmd/1). Forking is a problem when one runs massively large<br>
Erlang/VM instances, as we (Klarna) do. With erl_child_setup, the<br>
fork() is done inside that much smaller helper process. So I think it<br>
needs to stay, but the mechanics of starting it might need adapting<br>
for Android.<br>
<br>
I take it you don't use heart, because that's also a separate executable.<br>
</blockquote></div></div></div>