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

[pantsd] Investigate removing forking from DaemonPantsRunner #7390

Closed
blorente opened this issue Mar 15, 2019 · 5 comments
Closed

[pantsd] Investigate removing forking from DaemonPantsRunner #7390

blorente opened this issue Mar 15, 2019 · 5 comments
Assignees
Milestone

Comments

@blorente
Copy link
Contributor

There are some issues around fork safety (#7380, #6714, possibly duped by #7323), which make it worth considering how hard it would be to remove forking from that class.

There are possible workarounds for both issues, but we have no guarantees that those workarounds will continue to work in newer versions of OSX.

Therefore, it would be good to list blockers for removing forking from DaemonPantsRunner.

@cosmicexplorer
Copy link
Contributor

cosmicexplorer commented Mar 15, 2019

It's very sad to me that forking isn't a viable strategy in 2019, but moving to v2 to eventually circumvent the need for forking makes me happy enough.

The DaemonPantsRunner would need to avoid exiting, but since we've parameterized exiting into the DaemonExiter, this shouldn't be incredibly hard, even with signal handling.

If we removed forking, would we end up running pants synchronously? Would we have to have some non-python way of having concurrent pailgun requests block?

@ity ity self-assigned this Mar 18, 2019
@ity
Copy link
Contributor

ity commented Mar 19, 2019

Two questions I am trying to answer in parallel (touché):

  1. Why do we fork? Pros/cons?
  2. How much global state do we have to manage if we weren’t to fork?

Aspects to consider to implement no-fork:

  • Any Blockers?
  • Possible performance loss
  • Elegant way to process tasks in parallel (fork) vs the alternative
  • Note: can only run 1 pants process at a time(because of the GIL)
  • Estimate Effort to implement

@stuhood
Copy link
Member

stuhood commented Mar 21, 2019

@ity
Copy link
Contributor

ity commented Mar 25, 2019

Some of the workarounds and investigation results to make pantsd work without forking:

  1. Subsystems (are reset already, so this might not be an issue after all)
  2. Exiter (removed the call to it)
  3. ExceptionSink (removed the call to it)
  4. Logger (maximum recursion issue as its initialized (setup_logging) in the daemon and then subsequently in LocalPantsRunner, to bypass the issue disabled the initialization of the logger in LocalPantsRunner but this would have to be addressed)
  5. Concurrency:
    a) Multiple clients at the same time
    b) People piping pants into pants
    c) can conditionally disable pantsd for the 2nd run
  6. Memory leaks
    a) cyclic garbage collection (read Python documentation on this)
    b) needs further investigation

stuhood pushed a commit that referenced this issue Apr 4, 2019
### Problem

See #7439. 

### Solution

Use `psutil` to get the current memory usage of the daemon under test. Even pre-#7390, memory usage already seems to grow roughly linearly by about 3MB per run for this particular command. 

Fixes #7439.
@stuhood stuhood added this to the 1.16.x milestone Apr 19, 2019
@ity ity mentioned this issue Apr 19, 2019
2 tasks
@blorente
Copy link
Contributor Author

blorente commented May 9, 2019

I think this can be closed now, we opened follow-up issues.

@blorente blorente closed this as completed May 9, 2019
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

No branches or pull requests

4 participants