Skip to content

Reduce and isolate usage of Dir.chdir #383

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

Closed
wants to merge 2 commits into from
Closed

Reduce and isolate usage of Dir.chdir #383

wants to merge 2 commits into from

Conversation

taquitos
Copy link
Contributor

Instead of using chdir blocks, we should use absolute paths so that we can enable threaded usage of the library
If Process.fork() is available, we'll use that for git.chdir actions, otherwise, we'll use a global mutex to
prevent threads from calling git.chdir before the previous execution has completed.

Note: if you do async work in git.chdir all bets are off.

Your checklist for this pull request

🚨Please review the guidelines for contributing to this repository.

  • Ensure all commits include DCO sign-off.
  • Ensure that your contributions pass unit testing.
  • Ensure that your contributions contain documentation if applicable.

Signed-off-by: Joshua Liebowitz taquitos@google.com

Instead of using chdir blocks, we should use absolute paths so that we can enable threaded usage of the library
If Process.fork() is available, we'll use that for git.chdir actions, otherwise, we'll use a global mutex to
prevent threads from calling git.chdir before the previous execution has completed.
- fork() when using Dir.chdir, otherwise, use a mutex
- wrap calls to in a semaphore
- replace Dir.chdir with paths
- fixes #355

Note: if you do async work in git.chdir all bets are off.

Signed-off-by: Joshua Liebowitz <taquitos@google.com>
@taquitos
Copy link
Contributor Author

@perlun, this one should be good to go as soon as CI is done. I squashed all my commits into 1.

Copy link
Contributor

@tarcinil tarcinil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me. 👍

Copy link
Contributor

@perlun perlun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A very good change, thanks @taquitos. I had some remaining questions that I would like to be settled before merge.

else
do_get.call
if @git_dir
Dir.chdir(@git_dir, &do_get)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This part is still non-threadsafe - was this intentional?

else
build_list.call
if @git_dir
Dir.chdir(@git_dir, &build_list)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likewise, not thread-safe.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I thought I took care of these, might just be a merge issue. I'm offline for a week now, but will take a look.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@perlun and @taquitos isn't the purpose of the semaphore to make these thread safe?

@mib32
Copy link

mib32 commented Oct 10, 2018

I am interested, how this will work inside a Sidekiq worker, which is known for it's inability to fork processes sidekiq/sidekiq#783 (comment)

Perhaps whether we use fork vs mutex can also be a customizable option

@perlun
Copy link
Contributor

perlun commented Oct 29, 2018

@taquitos Any updates on this? It would be nice to get it merged, sooner or later.

@taquitos
Copy link
Contributor Author

taquitos commented Nov 1, 2018

Unfortunately I won't have time to continue this PR. I've joined a new team and am no longer working on Ruby things, and my free time is pretty limited these days. Of course, anybody should feel free to continue to pull this over the finish line.

@perlun
Copy link
Contributor

perlun commented Nov 5, 2018

Unfortunately I won't have time to continue this PR. I've joined a new team and am no longer working on Ruby things, and my free time is pretty limited these days.

Fair enough - it's unfortunately quite the same for me, I've switched jobs and is no longer working on Ruby things either. 😊 So... unless someone (@tarcinil , @mib32) is willing to pick up the gauntlet on this one, I suspect it will be auto-closed in a few months, regretfully. I think it was a really great initiative since thread safety is not an option; it should be the default in all code we write, and non-thread-safe is really "opt in" for extreme circumstances.

Regretfully, this is not really the case with our code base as it is so if people feel like volunteering to fix it - I am more than happy to see it coming.

@stale
Copy link

stale bot commented Jan 5, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 5, 2019
@tarcinil tarcinil added pinned and removed wontfix labels Jan 7, 2019
@jcouball
Copy link
Member

Closing due to lack of interest. If anyone wants to take this up, I am happy to help with review. This also needs a test.

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.

Using one repo per thread results in errors
5 participants