Re: master 8c81818673a 6/7: Tune volatile in read_char

[Pip Cet <pipcet@protonmail.com>]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Mon, 19 Aug 2024 15:32:40 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Andrea Corallo <acorallo@gnu.org>, eggert@cs.ucla.edu, emacs-devel@gnu.org, stefankangas@gmail.com
>>
>> "Eli Zaretskii" <eliz@gnu.org> writes:
>>
>> >> Don't know what the other maintainers think about this but FWIW I don't
>> >> like this change (and similar ones).  Our codebase is already
>> >> sufficiently tricky and convoluted, complexifying code for no observable
>> >> improvements should be IMO out of our goals.
>> >
>> > I tend to agree.  Especially given that the rationale for this
>> > juggling and why exactly we assign and re-assign these two variables
>> > in those particular places is nowhere to be found, neither in the
>> > source code nor in the commit log message.
>>
>> Could we measure the performance impact of making all stack variables in
>> functions that call setjmp() volatile?
>
> Why would that be useful?  (Many/most of them already are volatile.)

Because we will run into further setjmp()-related bugs if we don't do
it, and because we could then stop putting effort into deciding under
which delicate circumstances we can make them non-volatile (which is
fun, I understand that).

> In any case, this is not what this thread is about, so let's not mix
> together unrelated issues.

This thread is about how to deal with automatic variables in
setjmp()-calling functions, either duplicating them into a 'c_volatile'
/ 'c' pair, as Paul's patch did, or keeping a single volatile
variable. I think "let's make all of them volatile" is an obvious
simplification of that idea.

Pip