Skip to content

Conversation

@DougBurke
Copy link
Contributor

@DougBurke DougBurke commented Apr 23, 2024

Summary

Ensure that Sherpa does not change the global multiprocessing state but instead uses the (new) sherpa.utils.parallel.context attribute. Fix #1015.

Details

The multiprocessing documentation states, within https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods

A library which wants to use a particular start method should probably use get_context() to avoid interfering with the choice of the library user.

This PR does this, making the context available as sherpa.utils.parallel.context.

I also made a small change to a callback routine since we don't need to send in the queues and lock since they are already ambient pieces of information (I do note that this is not great if we use spawn/forkserver but there are so many other issues there that I am working on that it's not an issue here - we can follow #2007 for that).

The coverage checks are not great because we do not actually run the multiprocessing code in our CI runs as thy tend to be run using an environment that only provides a single core, hence has no multiprocessing support.

This addresses issue sherpa#1015 and provides the

  sherpa.utils.parallel.context

field for code that wants to use Sherpa's multiprocessing
setup.
We don't need to send in the queues and lock since we can take
them from the existing context (i.e. local variables).
@DougBurke DougBurke marked this pull request as draft April 23, 2024 14:17
@codecov
Copy link

codecov bot commented Apr 23, 2024

Codecov Report

Attention: Patch coverage is 58.33333% with 15 lines in your changes are missing coverage. Please review.

Project coverage is 83.21%. Comparing base (1b368e3) to head (f59323f).

Additional details and impacted files

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #2006      +/-   ##
==========================================
+ Coverage   83.18%   83.21%   +0.03%     
==========================================
  Files          81       81              
  Lines       28294    28293       -1     
  Branches     4368     4368              
==========================================
+ Hits        23536    23544       +8     
+ Misses       4648     4639       -9     
  Partials      110      110              
Files Coverage Δ
sherpa/optmethods/opt.py 70.98% <100.00%> (-0.18%) ⬇️
sherpa/utils/parallel.py 81.52% <82.35%> (-0.83%) ⬇️
sherpa/estmethods/__init__.py 77.66% <25.00%> (+0.19%) ⬆️

... and 1 file with indirect coverage changes


Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1b368e3...f59323f. Read the comment docs.

@DougBurke DougBurke changed the title Multiprocessing updates Use a separate context when handling multiprocessing calls Apr 24, 2024
@DougBurke DougBurke marked this pull request as ready for review April 24, 2024 16:17
@DougBurke DougBurke requested a review from hamogu April 24, 2024 16:18
@wmclaugh wmclaugh merged commit d99d3ac into sherpa:main Apr 25, 2024
@DougBurke DougBurke deleted the multiprocessing-updates branch April 26, 2024 02:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

multiprocessing code: we should use get_context rather than changing the global context

3 participants