Skip to content

Add multiprocessing compatibility wrapper for macOS/Windows#4734

Open
gamesh411 wants to merge 2 commits intoEricsson:masterfrom
gamesh411:add-multiprocessing-wrapper-to-support-osx
Open

Add multiprocessing compatibility wrapper for macOS/Windows#4734
gamesh411 wants to merge 2 commits intoEricsson:masterfrom
gamesh411:add-multiprocessing-wrapper-to-support-osx

Conversation

@gamesh411
Copy link
Contributor

Fixes #4733

This PR adds a compatibility wrapper for multiprocess.Pool on macOS/Windows platforms that provides a ProcessPoolExecutor-like API, ensuring consistent interface across platforms.

Changes

  • Add Pool wrapper class that accepts max_workers parameter (converted to processes for multiprocess.Pool)
  • Support context manager protocol (with statement)
  • Implement map() with multiple iterables support (matching ProcessPoolExecutor.map())
  • Provide close() and join() methods

This allows code to use max_workers consistently on all platforms without platform-specific conditionals.

Background

The platform-specific multiprocessing implementation is necessary because:

  • On macOS/Windows: The multiprocess package (third-party) is used instead of standard multiprocessing due to reliability issues (see commits 803e446, d56e216)
  • On Linux: ProcessPoolExecutor from standard library is used
  • The compatibility layer bridges API differences between these implementations
Add a Pool wrapper class that provides ProcessPoolExecutor-like API for multiprocess.Pool on darwin and win32 platforms. This ensures consistent interface across platforms by: - Accepting max_workers parameter (converted to processes) - Supporting context manager protocol (with statement) - Implementing map() with multiple iterables support - Providing close() and join() methods This allows code to use max_workers consistently on all platforms without platform-specific conditionals. The platform-specific multiprocessing implementation is necessary because: - On macOS/Windows: The multiprocess package (third-party) is used instead of standard multiprocessing due to reliability issues (see commits 803e446, d56e216) - On Linux: ProcessPoolExecutor from standard library is used - The compatibility layer bridges API differences between these implementations
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

1 participant