Ole Streicher <oleb...@debian.org> (2015-09-28): > The CI tests run here are the same as in during the build process, where > they succeed. Since it is a specific test that fails, I guess that it is > not just the different location (build tree vs. installed version), but > the environment that is different. Specifically, I guess that the > problem is the following python test [2]: > > --------------------------------8<-------------------------------------- > PY3_4 = sys.version_info[:2] >= (3, 4) > > # Used for the below test--inline functions aren't pickleable > # by multiprocessing? > def _square(x): > return x ** 2 > > @pytest.mark.skipif('not PY3_4 or sys.platform == "win32" or > sys.platform.startswith("gnu0")') > def test_multiprocessing_forkserver(): > """ > Test that using multiprocessing with forkserver works. Perhaps > a simpler more direct test would be to just open some local > sockets and pass something through them. > > Regression test for https://github.com/astropy/astropy/pull/3713 > """ > > import multiprocessing > ctx = multiprocessing.get_context('forkserver') > pool = ctx.Pool(1) > result = pool.map(_square, [1, 2, 3, 4, 5]) > pool.close() > pool.join() > assert result == [1, 4, 9, 16, 25] > --------------------------------8<-------------------------------------- > > Is there a reason why this could block in the CI context?
A common issue with multiprocessing is the lack of /dev/shm; you would usually get something like "function not implemented" though. You may want to check things like: https://docs.python.org/dev/library/multiprocessing.html https://bugs.python.org/issue3770 Mraw, KiBi.
signature.asc
Description: Digital signature