Re: Are NIF resources meant to be destroyed immediately on GC?

As a general rule: never use finalizers for the primary resource
reclamation path. You don't know when they'll run. You don't know what
changes are made to a GC in the future, that alters the rule set slightly.
Use them as a safety measure if something goes out of scope. Resources such
as DB connections can be very limited in scope (less than 50 for a typical
non pg_bouncer postgres setup). So you have to manage them quite
explicitly. Memory is far more abundant, and it is also fungible to a large
extent, so you just need a block somewhere.

This is true in *any* GC language I've worked with over the years. There
may come something along which completely changes the landscape, but it
hasn't happened yet. It's more in the other direction (see e.g.,
Ephemerons[0]) that things are progressing.

[0] https://en.wikipedia.org/wiki/Ephemeron

On Wed, Nov 25, 2020 at 10:54 AM Sean Hinde <[email protected]> wrote:

>
> This a really nice change. It opens the door to resource destructors being
> safe for closing external resources like database handles that might take a
> while.
>
> Super cool!
>
> Sorry to disappoint, but no.
> By ”scheduled” I just meant “put in run queue to be executed at a later
> time”. Destructors are still executed by a normal scheduler threads and not
> dirty schedulers.
>
>
> Ah well! I still think it would be pretty handy. It would make that kind
> of code much easier to get right, safer, and potentially more efficient.
>
> Sean
>
>

-- 
J.