<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">[0] <a href="https://en.wikipedia.org/wiki/Ephemeron">https://en.wikipedia.org/wiki/Ephemeron</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 25, 2020 at 10:54 AM Sean Hinde <<a href="mailto:sean.hinde@mac.com">sean.hinde@mac.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><div><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><br><div><div style="margin:0cm 0cm 0.0001pt 65.2pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt 65.2pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt 65.2pt;font-size:11pt;font-family:Calibri,sans-serif">Super cool!<u></u><u></u></div></div><div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">Sorry to disappoint, but no.<u></u><u></u></span></div><div style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">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.</span></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>Sean</div></div><br></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature">J.</div></div>