Boszormenyi Zoltan <z...@cybertec.at> writes:
>> The volatile marking shouldn't even be necessary there.
>> The signal handler doesn't writes to it, only the main code.
Well, (a) that's not the case in the patch as committed, and (b) even if
it were true, the volatile marking is still *necessary*, because that's
what tells the compiler it can't optimize away changes to the variable,
say on the grounds of there being another store with no intervening
fetches in the main-line code. Without that, a compiler that had
aggressively inlined the smaller functions could well deduce that the
disable_alarm() assignment was useless.
> Also, since the the variable assignment doesn't depend on other code
> in the same function (or vice-versa) the compiler is still free to
> reorder it.
> Volatile is about not caching the variable in a CPU register since
> it's "volatile"...
I don't believe you understand what volatile is about at all. Go read
the C standard: it's about requiring objects' values to actually match
the nominal program-specified values at sequence points. A more
accurate heuristic is that volatile tells the compiler there may be
other forces reading or writing the variable besides the ones it can see
in the current function's source code, and so it can't drop or reorder
accesses to the variable.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
