1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
|
From: Sebastian Ramacher <sramacher@debian.org>
Date: Mon, 16 Apr 2018 01:02:09 +0200
Subject: Do not run multiprocessing test if multiprocessing.synchronize is
not working
On platforms that do not have a working sem_open implementation, importing
multiprocessing.synchronize will fail with an ImportError. While creating a
multiprocessing.Pool instance, multiprocessing.synchronize will be imported and
might throw an ImportError.
Forwarded: yes, https://github.com/dlitz/pycrypto/pull/61
Last-Update: 2013-10-17
---
lib/Crypto/SelfTest/Random/test__UserFriendlyRNG.py | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/lib/Crypto/SelfTest/Random/test__UserFriendlyRNG.py b/lib/Crypto/SelfTest/Random/test__UserFriendlyRNG.py
index 771a663..3fd7ad4 100644
--- a/lib/Crypto/SelfTest/Random/test__UserFriendlyRNG.py
+++ b/lib/Crypto/SelfTest/Random/test__UserFriendlyRNG.py
@@ -39,6 +39,11 @@ from Crypto.Util.py3compat import *
try:
import multiprocessing
+ # multiprocessing.Pool uses classes from multiprocessing.synchronize, so we
+ # need to check if multiprocessing.semaphore will work. Otherwise creating a
+ # multiprocessing.Pool instance will fail with an ImportError. See Python
+ # bug #3770 for details.
+ import multiprocessing.synchronize
except ImportError:
multiprocessing = None
|
