[erlang-bugs] heart prevents beam from creating crash dumps

[Erik Søe Sørensen]

On 27-08-2012 10:16, Paul Guyot wrote:
>> It would be great if there was a way of simply figuring out the file
>> descriptor numbers used for EPMD and/or heart from the C code. Then it
>> would be easy to fix this. One possibility is to add a new BIF that
>> stores the current EPMD port in a C variable. Then the loop that closes
>> all ports could be replaced with a single close.
> I would like to strongly argue against a selected close of the epmd port.
>
> The main argument is that it singles out the node name as the only exclusive resource a node can have.
I was thinking the same thing, but about listening sockets.
It'd probably make better sense to make the heart FD be the special 
case, like stdin/out/err are already.

Alternatively, could the node communicate to heart that it is dumping, 
so that heart can leave it be (at least for a while)? That would of 
course also make the FD special, so probably no gain.

Is kill-on-close the right behaviour for heart? The "if the connection 
to Erlang breaks, it assumes the Beam process has gone bad" reaction, is 
it justified? That could be changed to "if the connection breaks, then 
assume - at least for a while - that the Beam process is going down." 
If, after a timeout after the connection disappeared, the Beam process 
is still around (or, possibly, that heart observes no growth in the dump 
file... don't know if that's too much complexity), *then* go assume 
badness and go for the kill. For great justice.

2¢
/Erik

>   Other resources cannot be shared between incarnations of the same node. For example, a node may open a pool of N connections to a database server which could be limited, by configuration, to a total count of M connections where M < 2 * N.
>
> Paul


-- 
Mobile: + 45 26 36 17 55 | Skype: eriksoesorensen | Twitter: @eriksoe
Trifork A/S  |  Margrethepladsen 4  |  DK-8000 Aarhus C | 
www.trifork.com <http://www.trifork.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20120827/f61f0869/attachment.htm>