Re: [PATCH] lock_timeout and common SIGALRM framework

2012-07-03 23:38 keltezéssel, Alvaro Herrera írta:
>
> I don't understand why PGSemaphoreTimedLock() is not broken. I mean
> surely you need a bool return to let the caller know whether the
> acquisition succeeded or failed?

Well, this is the same interface PGSemaphoreTryLock() uses.
By this reasoning, it's also broken.

> AFAICS you are relying on
> get_timeout_indicator() but this seems to me the wrong thing to do ...
> (not to mention how ugly it is to percolate through two levels of
> abstraction)

What other way do you suggest? EINTR may come from
a different signal, which may also be ignored or not. Ctrl-C
is handled and leads to elog(ERROR) but an ignored signal
technically calls a NOP handler deep inside the OS runtime
libraries but the signal *is* delivered to the backend which
in turn interrupts semop() or whatever the platform equivalent is.

I can add a flag to timeout.c that is set whenever SIGALRM
is delivered but checking that would be another "abstraction
violation" as calling get_timeout_indicator() in your opinion.

The original coding of PGSemaphoreTryLock() used
semtimedop(), sem_timedwait() and the timeout value applied
to WaitForMultipleObjectsEx(). This was quickly shot down
as using the SIGALRM signal and its behaviour to interrupt the
locking operation is be better and fits the PostgreSQL portability
features. Also, OS X at the time didn't support sem_timedwait().

I am not complaining, just recalling the different details.

How about not hardcoding get_timeout_indicator(LOCK_TIMEOUT)
into PGSemaphoreTimedLock()? Passing TimeoutName to it would
make it more generic and usable for other timeout sources.

--
----------------------------------
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/