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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
