Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiprocessing Semaphore and BoundedSemaphore - incomplete features ('get_value' missing) on MacOSX. #125828

Open
YvesDup opened this issue Oct 22, 2024 · 0 comments
Labels
topic-multiprocessing type-bug An unexpected behavior, bug, or error

Comments

@YvesDup
Copy link
Contributor

YvesDup commented Oct 22, 2024

Bug report

Bug description:

I've been working on this PR: Adding multiprocessing queue shutdown feature for a while on my Mac machine. I've come up with a solution for this new feature and wanted to check that it also worked on Linux. However, I had forgotten that BoundedSemaphore is not fully functional on MacOSX. In fact, there's no check for exceeding the upper bound. See this example:

import multiprocessing as mp
bs = mp.BoundedSemaphore(2)
print(bs) # <BoundedSemaphore(value=unknown, maxvalue=2)>  note invalid representation string 
bs.release() # Succeed with MacOSX, Raise an exception on Linux 

I had to revise my solution because it was invalid on Linux. Such a shame, I wasted a lot of time. I checked on the documentation a few days ago . There is not a specific warning about this case.

As a reminder, the initial reason is the absence of the sem_getvalue C function in the MacOSX semaphore implementation. This prevents retrieval of the current semaphore value. It also prevents the Semaphore use as a shared counter. This issue is (very ?) old, and still hasn't been solved from Apple, could a workaround be implemented on MacOSX, so that Semaphore and BoundedSemaphore would have the same functionalities as Linux/Win.

A workaround (in Python) would be to use a shared value and to revise the acquire and release methods in order to emulate the semaphore internal counter. It is quite possible that this solution would greatly reduce performance.

I've already done a lot of tests (See the attached draft PR). And also, this solution should fix the representation strings that are currently wrong.

Before going any further, I was wondering if there's a reason why no patch attempt has been implemented ? And was there an old discussion about this already ?

Thanks for your feedback

CPython versions tested on:

3.10, 3.11, 3.12, 3.13, CPython main branch

Operating systems tested on:

macOS

Linked PRs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-multiprocessing type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants