Patch to_s timeout by mclark · Pull Request #631 · libgit2/rugged · GitHub
Skip to content

Patch to_s timeout#631

Closed
mclark wants to merge 10 commits into
libgit2:masterfrom
mclark:patch-to_s-timeout
Closed

Patch to_s timeout#631
mclark wants to merge 10 commits into
libgit2:masterfrom
mclark:patch-to_s-timeout

Conversation

@mclark

@mclark mclark commented Sep 9, 2016

Copy link
Copy Markdown

When calculating very large patches, there is the potential for the call to hang for a while without any feedback to the caller.

Potentially this could manifest itself in one of two places:

  1. Calculating the diff_hunks in the original diff
  2. Translating the lines of those hunks into ruby strings

This patch addresses the latter and gives us a mechanism to bail early when the diff output is taking too long.

I'm not sure if there is a clear path to addressing a timeout in the former case, but I am open to suggestions and feedback on both ideas.

Thanks so much to @brianmario for 🍐 ing with me on this one!

@mclark mclark changed the title Patch to s timeout Patch to_s timeout Sep 9, 2016
Comment thread ext/rugged/rugged_patch.c Outdated

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Let's please use clock_gettime with CLOCK_MONOTONIC here.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@vmg we can probably just #ifdef this but clock_gettime doesn't exist on OSX until Sierra.

For now we could either stick with gettimeofday on OSX or mach_absolute_time? It may not work exactly the same as clock_gettime, but I think it's monotonic?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

FWIW, any time functions in libgit2 use clock_gettime(CLOCK_MONOTONIC... when it's available and fall back to gettimeofday. We never use mach_absolute_time, so that might be a precedent for you.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@ethomson oh cool ok, let's just run with that then :)

@mclark we can pair on this again tomorrow if you'd like?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

@vmg

vmg commented Sep 10, 2016

Copy link
Copy Markdown
Member

Looks pretty good. Let's switch to a monotonic clock please. :)

Comment thread ext/rugged/time.h Outdated
return (double)time * scaling_factor / 1.0E9;
}

#elif defined(AMIGA)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Rugged does not support AMIGA. :)

@vmg

vmg commented Sep 12, 2016

Copy link
Copy Markdown
Member

Looking good @mclark. As you can see, we can drop a lot of libgit2's original code because we support fewer platforms. That's good news!

Please do that and ping me back so I can audit the remaining code against libgit2's original blame -- as it is an OSS project, we cannot magically relicense it from GPLv2 to MIT without asking the contributors. Unless the contributors are @carlosmn and @ethomson. In that case we can, because we pay them money to abuse their copyright. 👌

@mclark

mclark commented Sep 13, 2016

Copy link
Copy Markdown
Author

thanks @brianmario for catching that one! C is weird! 😛

@vmg All concerns save the legal ones have been addressed. I can rebase this to clean it up if you like before we proceed.

@mclark

mclark commented Feb 28, 2023

Copy link
Copy Markdown
Author

@mclark mclark closed this Feb 28, 2023
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.

4 participants