homepage

This issue tracker has been migrated to GitHub , and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients pitrou, vstinner
Date 2017年09月21日.10:37:36
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1505990256.17.0.849491496328.issue31510@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2017年09月21日 10:37:36vstinnersetrecipients: + vstinner, pitrou
2017年09月21日 10:37:36vstinnersetmessageid: <1505990256.17.0.849491496328.issue31510@psf.upfronthosting.co.za>
2017年09月21日 10:37:36vstinnerlinkissue31510 messages
2017年09月21日 10:37:36vstinnercreate

AltStyle によって変換されたページ (->オリジナル) /