[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: sqlite memory allocation and async signal safety
From: |
Po Lu |
Subject: |
Re: sqlite memory allocation and async signal safety |
Date: |
Thu, 24 Mar 2022 18:22:28 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) |
Eli Zaretskii <eliz@gnu.org> writes:
> I think we used to block input around function calls that could
> allocate memory because our signal handlers, and in particular SIGIO
> handler, did non-trivial stuff. Nowadays our signal handlers just set
> a flag and return, so I'm not sure this is needed anymore. Especially
> when system library malloc is called, which AFAIU is mostly async-safe
> nowadays on modern platforms.
>
> Am I missing something?
Unfortunately, most system malloc implementations are still not
async-signal safe, but if all that happens is a flag being set, then I
don't think calling block_input is required anymore.
Which flag is that, and where is it tested?
> memory_full means basically that the user should save and exit ASAP.
> Is that indeed required when SQLite runs out of memory? Isn't it
> enough to just fail the SQLite-related function?
That's why I asked the second question: SQLite is supposedly very good
at coping with allocation failures, so when the memory allocation fails,
it probably means there is really no memory left.
> I see no reason to go to our malloc as long as SQLite is not supposed
> to be invoked before dumping Emacs.
>
> I'd like to hear others about these issues, though, as I'm not enough
> of an expert on this stuff.
Indeed, thanks for clarifying.