Implications of setting SIGCHLD in relation to NIFs

José Valim jose.valim@REDACTED
Tue Nov 17 16:33:13 CET 2020


Thanks for the further clarifications! Do you think it is worth adding a
note to the docs? Something like this:

> The Erlang runtime sets SIGCHLD to ignore by default. This allows the
runtime
> to run as the root process (PID=1) inside containers and not leak zombie
PIDs.
> If you plan to change said signal, be mindful of the consequences it may
have
> in such cases. Note this behaviour and this message may change in the
future.

I understand if you don't want to write it down though. For now we will set
it back to the default when compiling and add a note for users of this
particular library so people don't run Elixir as the root process on the
Docker.

*José Valimhttps://dashbit.co/ <https://dashbit.co/>*


On Tue, Nov 17, 2020 at 4:21 PM Lukas Larsson <lukas@REDACTED> wrote:

>
>
> On Mon, Nov 16, 2020 at 10:02 PM José Valim <jose.valim@REDACTED> wrote:
>
>> I see, thanks Lukas!
>>
>> Two follow up questions (please consider that I am not well versed in C):
>>
>> 1. Is there another option we could use instead of waitpid, in case we
>> try to patch upstream?
>>
>>
> I didn't read their code very thoroughly before and it seems like they
> call waitpid with a given pid and not -1 as I assumed, so it may be that
> their code is safe. I don't know of any better alternative.
>
> 2. Instead of ignoring, could Erlang install a handler that removes the
>> zombie processes once invoked?
>>
>>
> We could, but if I remember correctly we would still have to do multiple
> waitpid(-1) calls which could end up breaking exactly what tensorflow is
> doing there, but maybe the WIFEXITED call takes care of that. It was a long
> time since I had to figure out all of these things and I don't remember the
> details of how all this works together on all platforms.
>
>
>>
>>
>> --
>>
>>
>> *José Valimhttps://dashbit.co/ <https://dashbit.co/>*
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20201117/5949265c/attachment.htm>


More information about the erlang-questions mailing list