Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings

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

Copy link
Copy link
Open
@YvesDup

Description

@YvesDup
Issue body actions

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

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Morty Proxy This is a proxified and sanitized view of the page, visit original site.