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

[Eli Zaretskii]

> Date: Mon, 19 Aug 2024 11:59:28 -0700
> Cc: acorallo@gnu.org, emacs-devel@gnu.org, stefankangas@gmail.com
> From: Paul Eggert <eggert@cs.ucla.edu>
> 
> On 2024-08-19 09:15, Eli Zaretskii wrote:
> > Why not simply undo that single patch, and be done?
> 
> Let's not. The issue has long been present and is not limited to 
> read_char; see, for example, the variable "this_op" in exec_byte_code, 
> which is merely a volatile copy of "op". The method Emacs uses to 
> address this issue works and there's no reason to use a different method 
> in read_char than everywhere else.

I'm talking only about that particular change, whose motivation is
described as "Optimize access to a local volatile."  If this is just
an optimization, and its effect on performance is as you describe it,
but it has a downside of making the code harder to read and maintain,
why not pay that small penalty in performance?

> A better way to deal with 'volatile' is to not use it, the way Stefan 
> did in 2013; see commit adf2aa61404305e58e71cde0193bb650aff2c4b3.

I have nothing against 'volatile' in general.  Once again, this is
only about the "optimization" part of your changes.