Re: sqlite memory allocation and async signal safety

[Eli Zaretskii <eliz@gnu.org>]

> From: Po Lu <luangruo@yahoo.com>
> Date: Thu, 24 Mar 2022 17:06:28 +0800
> 
> SQLite allocates various pieces of memory inside most of its functions.
> This is done through the C library malloc, which immediately raises the
> reentrancy question: shouldn't input be blocked around such functions?

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?

> Secondly, SQLite returns an error code upon running out of memory in an
> irrecoverable fashion.  Shouldn't the code that currently signals an
> ordinary error in such situations call `memory_full' instead?

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?

> Alternatively, we could make SQLite call xmalloc instead of C library
> malloc, but I suppose the SQLite library is better at coping with
> allocation failures of large sizes than xmalloc is, so that's probably
> not the best solution.

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.