Hi ports@, I recently played around a bit with multiprocessing in Python. I learned that since OpenBSD has no support for named POSIX semaphores, things like multiprocessing.Semaphore() and .Queue() are disabled. Since this decreases the usability of multiprocessing, and since that's "the way to go" to make Python programs concurrent without hitting the GIL, that's quite a bummer.
Attached is an attempt at implementing the backend used by multiprocessing.Semaphore() using SYSV semaphores. These have the benefit that they can be shared across processes, opposed to the current implementation of POSIX semaphores. Upstream seems less than excited to adapt this idea (see [0]), but maybe a working implementation can convince them otherwise. I know the code is slightly ugly, especially the "detection" of the maximum value for a semaphore. I'm currently leaning towards using sysctl() to get the maximum value, but I don't know whether the value can be changed from inside the kernel (the sysctl is read-only in userspace), and how Python would react if the value were changed mid-run. The patched up Python passes all regression tests the port has to offer, with the exception of those that failed without it and one of the tests in multiprocessing. I'm looking into that, but simple things like a worker pool accessing a single work queue seem to work. What I'm looking for with this would be tests, and a general feeling of whether it's worth doing this. The attached tarball contains an updated version of lang/python/2.7, with the revision bumped. [0]: http://bugs.python.org/issue10348 -- Gregor Best
python-27-mp-sem.tar.gz
Description: application/tar-gz
