2013-03-18 06:22 keltezéssel, Boszormenyi Zoltan írta:
2013-03-18 03:52 keltezéssel, Tom Lane írta:
Boszormenyi Zoltan <z...@cybertec.at> writes:
2013-03-17 16:07 keltezéssel, Tom Lane írta:
It suddenly occurs to me though that there's more than one way to skin
this cat. We could easily add another static flag variable called
"sigalrm_allowed" or some such, and have the signal handler test that
and immediately return without doing anything if it's off. Clearing
and setting such a variable would be a lot cheaper than an extra
setitimer call, as well as more robust since it would protect us from
all sources of SIGALRM not just ITIMER_REAL.
Something like the attached patch?
Well, something like that, but it still needed some improvements. In
particular I thought it best to leave the signal handler still releasing
the procLatch unconditionally --- that behavior is independent of what
this module is doing. Also you seem to have some odd ideas about what
do-while will accomplish. AFAIK, in this usage it's purely a syntactic
trick without much semantic content. It's the marking of the variable
as "volatile" that counts for telling the compiler not to re-order
operations.
The volatile marking shouldn't even be necessary there.
The signal handler doesn't writes to it, only the main code.
I just put it there saying "why not?" to myself.
IIRC, volatile is needed if both the signal handler and the
main code changes the same variable.
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 got the reordering idea from here:
http://yarchive.net/comp/linux/compiler_barriers.html
Thanks for committing,
Zoltán Böszörményi
--
----------------------------------
Zoltán Böszörményi
Cybertec Schönig & Schönig GmbH
Gröhrmühlgasse 26
A-2700 Wiener Neustadt, Austria
Web: http://www.postgresql-support.de
http://www.postgresql.at/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
