Message274524
> The repro is tied to the time.sleep call in the try block. If I do time.sleep(1)
Yes - if both sleeps, the one in the `try` block and the one in the thread's routine (`sub`) are equal, then you'll have the typical race, and you can well be in the `finally` clause when the exception arises.
The problem though is different: please feel free to set the sleep in the `try` block to `sleep(100)` -- and unless the thread creation and startup takes 99 seconds, you should *not* run into that race, the problem however persists:
-------------------------------------------------------
merzky@thinkie:~ $ grep -C 2 sleep bug.py
def sub(pid):
time.sleep(1)
os.kill(pid, signal.SIGUSR2)
--
t = mt.Thread(target=sub, args=[os.getpid()])
t.start()
time.sleep(100)
except Exception as e:
print 'except: %s' % e
merzky@thinkie:~ $ while true; do i=$((i+1)); echo -n "$i: "; python bug.py || break; done
1: except: caught sigusr2
2: except: caught sigusr2
3: except: caught sigusr2
4: Traceback (most recent call last):
File "bug.py", line 30, in <module>
print 'unexcepted'
File "bug.py", line 14, in sigusr2_handler
raise RuntimeError('caught sigusr2')
RuntimeError: caught sigusr2
------------------------------------------------------
In this case, the begaviour does depend on `ctypes` -- or at least I have not seen that problem without `ctypes` being used.
Thanks, Andre. |
|
Date |
User |
Action |
Args |
2016-09-06 05:29:59 | Andre Merzky | set | recipients:
+ Andre Merzky, eryksun, gslavin |
2016-09-06 05:29:59 | Andre Merzky | set | messageid: <1473139799.55.0.412656513294.issue27889@psf.upfronthosting.co.za> |
2016-09-06 05:29:59 | Andre Merzky | link | issue27889 messages |
2016-09-06 05:29:59 | Andre Merzky | create | |
|