[erlang-questions] Deterministic destruction of NIF resources

[Loïc Hoguin]

Wow, nice tip!

Wonder if anything can be done to fix it? Perhaps the repl can check if 
a variable is/contains a resource and replace it with <<>> for further 
usage? Can that be done?

On 07/18/2016 10:30 AM, John Doe wrote:
> They are often held by the repl. If one prints an allocated resource in
> Erlang console it won't be released.
>
> 2016-07-17 10:37 GMT+03:00 Lukas Larsson <garazdawi@REDACTED
> <mailto:garazdawi@REDACTED>>:
>
>
>
>     On Sat, Jul 16, 2016 at 10:06 AM, Roger Lipscombe
>     <roger@REDACTED <mailto:roger@REDACTED>> wrote:
>
>
>         In my testing, the destructor is delayed by a few seconds (when
>         repeatedly -- manually, so not particularly quickly --
>         restarting one
>         test process). In production, we're seeing the destructor being
>         delayed an arbitrarily long period, which is kinda important,
>         because
>         the destructor is responsible for killing a background thread, and
>         we'd prefer it not to continue after the associated Erlang
>         process has
>         died.
>
>         As far as I can tell from reading the OTP source, it looks like
>         resources are allocated from the binary heap, rather than any
>         particular process heap, which suggests to me that they'll be
>         collected when the binary heap undergoes a GC. What triggers that?
>
>
>     The binary heap never undergoes a gc, there is just the term heap
>     gc. The binaries (which as you say include nif resources) are
>     reference counted and de-allocated when all references are gone. I
>     can't say for sure why your references are being held on for longer,
>     if you want to dig deeper:
>
>     * the sweep of the binaries is
>     here: https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L11674
>     * the deletion of the process is
>     here: https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_process.c#L12857
>     * the calling of the destructor is done by erts_bin_free here:
>     https://github.com/erlang/otp/blob/maint/erts/emulator/beam/erl_message.c#L171
>
>     One of the great mantras of ERTS is "Why do it now when it would be
>     cheaper/easier to do it later". So it may well be that something
>     somewhere along the path delays and batches all the operations up.
>
>     As Max says, in order to be sure when the release will happen.
>     Release all references in the code and manually call the GC.
>
>     Lukas
>
>     _______________________________________________
>     erlang-questions mailing list
>     erlang-questions@REDACTED <mailto:erlang-questions@REDACTED>
>     http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang