From: Tomas Hlavaty <tom@logand.com>
To: Rudolf Schlatte <rudi@constantly.at>, emacs-devel@gnu.org
Subject: Re: using finalizers
Date: Mon, 03 Jan 2022 01:37:10 +0100 [thread overview]
Message-ID: <8735m5r6x5.fsf@logand.com> (raw)
In-Reply-To: <m2a6gec8jt.fsf@constantly.at>
On Sun 02 Jan 2022 at 19:11, Rudolf Schlatte <rudi@constantly.at> wrote:
> That being said, I'll try to express, in one exaggerated sentence, the
> deep cons of using gc for non-memory resources in the hope that it
> helps a bit:
>
> ”If you rely on the garbage collector to release non-memory resources as
> a side effect of reclaiming memory, you will run out of resources if you
> increase the main memory of your system.”
Is that your sentence? Or could you point me to the source for further
reading? I agree that the huge inbalance between the amount of
available memory and the amount of available file descriptors is a
problem. But the sentence does not explain the details. Is it the
consequence of Lisp running on a hosted operating system with those
constraints? Did for example lisp machines have the same constraints?
Why? Could EMFILE and ENFILE trigger gc and then retry open? sbcl does
finalize file descriptors and iirc some schemes close them automatically
too.
next prev parent reply other threads:[~2022-01-03 0:37 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-30 22:43 using finalizers Tomas Hlavaty
2021-12-31 2:46 ` LdBeth
2021-12-31 3:29 ` Stefan Monnier
2021-12-31 3:36 ` Stefan Monnier
2021-12-31 4:30 ` LdBeth
2021-12-31 4:43 ` LdBeth
2021-12-31 6:28 ` Tomas Hlavaty
2021-12-31 10:59 ` LdBeth
2021-12-31 11:18 ` Tomas Hlavaty
2021-12-31 11:41 ` LdBeth
2021-12-31 12:01 ` Tomas Hlavaty
2022-01-01 17:00 ` Stefan Monnier
2022-01-01 20:25 ` Tomas Hlavaty
2022-01-01 20:47 ` Stefan Monnier
2022-01-01 22:55 ` Tomas Hlavaty
2022-01-01 23:18 ` Stefan Monnier
2022-01-01 23:47 ` Tomas Hlavaty
2022-01-01 23:26 ` Tomas Hlavaty
2021-12-31 7:50 ` Eli Zaretskii
2021-12-31 9:31 ` Tomas Hlavaty
2021-12-31 12:27 ` Eli Zaretskii
2022-01-01 17:58 ` Tomas Hlavaty
2022-01-01 18:20 ` Eli Zaretskii
2022-01-01 20:55 ` Stefan Monnier
2022-01-01 23:05 ` Tomas Hlavaty
2022-01-01 23:21 ` Stefan Monnier
2021-12-31 14:23 ` Rudolf Schlatte
2021-12-31 16:21 ` Stefan Monnier
2022-01-01 17:37 ` Tomas Hlavaty
2022-01-01 22:36 ` Tomas Hlavaty
2022-01-02 6:54 ` Eli Zaretskii
2022-01-02 7:53 ` Tomas Hlavaty
2022-01-02 8:33 ` Eli Zaretskii
2022-01-02 13:10 ` Tomas Hlavaty
2022-01-02 14:42 ` Eli Zaretskii
2022-01-02 15:16 ` Eli Zaretskii
2022-01-02 17:18 ` Tomas Hlavaty
2022-01-02 18:11 ` Rudolf Schlatte
2022-01-03 0:37 ` Tomas Hlavaty [this message]
2022-01-04 3:08 ` Richard Stallman
2021-12-31 14:39 ` LdBeth
2022-01-01 17:59 ` Tomas Hlavaty
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8735m5r6x5.fsf@logand.com \
--to=tom@logand.com \
--cc=emacs-devel@gnu.org \
--cc=rudi@constantly.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).