Re: sqlite memory allocation and async signal safety

[Po Lu]

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.