[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: Oh, the pthread condvar+mutex implementation still has the bug, so I reopen the issue. -- resolution: fixed -> status: closed -> open ___ Python tracker ___

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: I merged my PR. Thanks Antoine Pitrou for the review! This change only impacts the io.BufferedWriter and io.BufferedReader during Python finalization. It has no effect on theading.Lock.acquire(). It might impact faulthandler.dump_traceback_later(), but in pra

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

Change by STINNER Victor : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: New changeset 850a18e03e8f8309bc8c39adc6e7d51a4568cd9a by Victor Stinner in branch 'master': bpo-30768: Recompute timeout on interrupted lock (GH-4103) https://github.com/python/cpython/commit/850a18e03e8f8309bc8c39adc6e7d51a4568cd9a --

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: To check if you are using pthread+semaphore, use: haypo@selma$ ./python -c 'import sys; print(sys.thread_info)' sys.thread_info(name='pthread', lock='semaphore', version='NPTL 2.25') Here you have pthread+semaphore. It's Fedora 26 running Linux kernel 4.13. -

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: I wrote PR 4103 to fix the pthread+semaphore implementation of PyThread_acquire_lock_timed(). Apply PR 4103, apply attached test.patch, recompile Python, and run interrupted_lock.py to test the PR. Result: haypo@selma$ ./python interrupted_lock.py acquire(t

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

Change by STINNER Victor : -- keywords: +patch pull_requests: +4073 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-li

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: Ah, I found another caller of PyThread_acquire_lock_timed() with a timeout > 0 and intr_flag=0: _enter_buffered_busy() of Modules/_io/bufferedio.c: /* When finalizing, we don't want a deadlock to happen with daemon * threads abruptly shut down

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: interrupted_lock.py: test threading.Lock.acquire(timeout=1.0) with SIGALRM sent every 1 ms (so up to 1000 times in total). Example: haypo@selma$ ./python interrupted_lock.py acquire(timeout=1.0) took 1.0 seconds and got 1000 signals Oh, in fact, threading.Lo

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: See also the PEP 475 "Retry system calls failing with EINTR" and PEP 418 (time.monotonic). -- ___ Python tracker ___ __

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

STINNER Victor added the comment: See also the old bpo-12822: "NewGIL should use CLOCK_MONOTONIC if possible.". -- ___ Python tracker ___

[issue30768] PyThread_acquire_lock_timed() should recompute the timeout when interrupted by a signal

New submission from STINNER Victor: The current code of PyThread_acquire_lock_timed() (the implementation not using semaphore) doesn't compute correctly the timeout when pthread_cond_timedwait() is interrupted by a signal. We should recompute the timeout using a deadline. Something like select