Ole Streicher <olebole@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.
Attachment:
signature.asc
Description: Digital signature