Message302681
test_many_processes() is made in two steps. The bug occurs at the second step which calls proc.terminate() on processes. Code of the test:
@classmethod
def _sleep_some(cls):
time.sleep(100)
@classmethod
def _test_sleep(cls, delay):
time.sleep(delay)
def test_many_processes(self):
if self.TYPE == 'threads':
self.skipTest('test not appropriate for {}'.format(self.TYPE))
sm = multiprocessing.get_start_method()
N = 5 if sm == 'spawn' else 100
# Try to overwhelm the forkserver loop with events
procs = [self.Process(target=self._test_sleep, args=(0.01,))
for i in range(N)]
for p in procs:
p.start()
for p in procs:
join_process(p)
for p in procs:
self.assertEqual(p.exitcode, 0)
procs = [self.Process(target=self._sleep_some)
for i in range(N)]
for p in procs:
p.start()
time.sleep(0.001) # let the children start...
for p in procs:
p.terminate()
for p in procs:
join_process(p)
if os.name != 'nt':
for p in procs:
self.assertEqual(p.exitcode, -signal.SIGTERM) # <--- HERE
I'm not sure about the "time.sleep(0.001) # let the children start...". It looks like a weak synchronization. Maybe if the system is heavily loaded, the signal is sent before Python registered signal handlers? 1 ms seems short to start Python. On my Linux laptop, it's closer to 15 ms. |
|
Date |
User |
Action |
Args |
2017-09-21 10:37:36 | vstinner | set | recipients:
+ vstinner, pitrou |
2017-09-21 10:37:36 | vstinner | set | messageid: <1505990256.17.0.849491496328.issue31510@psf.upfronthosting.co.za> |
2017-09-21 10:37:36 | vstinner | link | issue31510 messages |
2017-09-21 10:37:36 | vstinner | create | |
|