git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCHv2.1] t6500: wait for detached auto gc at the end of the test script

From
SZEDER Gábor <szeder.dev@gmail.com>
Date
Apr 13, 2017, 18:08 UTC
Message-ID
<CAM0VKjkA3O9YB5QpT+hBwt13FtQXOwiW5Fh3goSbi42V8rTzjQ@mail.gmail.com>
In-Reply-To
<20170413164451.quvt7xdzsm64lntp@sigill.intra.peff.net>
On Thu, Apr 13, 2017 at 6:44 PM, Jeff King <peff@peff.net> wrote:
> On Thu, Apr 13, 2017 at 12:31:38PM +0200, SZEDER Gábor wrote:
Show 5 quoted lines
> I did wonder what will happen if Windows learns to daemonize() the
> auto-gc. I don't think we'll get an immediate test failure, but this
> test will become racy again. But this time we'll actually notice the
> racy failure, because the "ls" will report extra packs if it runs before
> the background gc does. At which point we can revisit this.

Dscho said that it would take significant effort to make daemonize() work on Windows, so I guess it will take a while before we'll have to revisit this.

Show 7 quoted lines
> It would be nice if there were a non-racy way to detect whether we
> daemonized or not, and complain on Windows when we do. Then we'll be
> notified immediately when daemonize() changes by the test failure,
> rather than waiting for a racy failure.
>
> I guess we could probably grep for the "in the background" message from
> the parent gc. OTOH, maybe it is not even worth it.

That wouldn't work at the moment, because auto gc says that it will go to the background even on Windows.

As it is, auto gc first prints the "Auto packing the repo..." message, and calls daemonize() after that. Which message it prints, i.e. "in background" or not, depends solely on the value of the 'gc.autoDetach' config variable, which is true by default. The only platform-specific thing about all this is the #ifdef in daemonize(), but then it's already too late, the misleading message has already been printed.

See the discussion the patch for the same issue in a different test script (bb05510e5 (t5510: run auto-gc in the foreground, 2016-05-01)), including a patch at the end that prevents auto gc on Windows from lying about going to the background (which I, not being a Windows user, didn't follow through).

  http://public-inbox.org/git/20160505171430.Horde.-GuvDpZBfS8VI1Zcfn4bJQI@webmail.informatik.kit.edu/T/#u
> The racy version
> should fail reasonably promptly, I think, and the comments you've left
> would point any investigator in the right direction.
Previous: Jeff KingNext: Jeff King
Message 15 of 41 in “t6500: don't run detached auto gc at the end of the test script”
  1. t6500: don't run detached auto gc at the end of the test scriptSZEDER Gábor, Apr 10, 2017
  2. Jeff KingApr 10, 2017
  3. SZEDER GáborApr 10, 2017
  4. Jeff KingApr 10, 2017
  5. SZEDER GáborApr 10, 2017
  6. Jeff KingApr 10, 2017
  7. Johannes SixtApr 11, 2017
  8. SZEDER GáborApr 12, 2017
  9. Jeff KingApr 12, 2017
  10. SZEDER GáborApr 12, 2017
  11. [PATCHv2] t6500: don't run detached auto gc at the end of the test scriptSZEDER Gábor, Apr 12, 2017
  12. [PATCHv2.1] t6500: wait for detached auto gc at the end of the test scriptSZEDER Gábor, Apr 13, 2017
  13. David TurnerApr 13, 2017
  14. Jeff KingApr 13, 2017
  15. SZEDER GáborApr 13, 2017
  16. Jeff KingApr 13, 2017
  17. Jeff KingApr 13, 2017
  18. Stefan BellerApr 13, 2017
  19. Jeff KingApr 13, 2017
  20. SZEDER GáborApr 13, 2017
  21. Jeff KingApr 13, 2017
  22. SZEDER GáborApr 13, 2017
  23. Jeff KingApr 14, 2017
  24. SZEDER GáborApr 20, 2017
  25. Jeff KingApr 20, 2017
  26. test-lib: abort when can't remove trash directorySZEDER Gábor, Apr 20, 2017
  27. Jeff KingApr 20, 2017
  28. Junio C HamanoApr 21, 2017
  29. SZEDER GáborApr 21, 2017
  30. Jeff KingApr 21, 2017
  31. Junio C HamanoApr 24, 2017
  32. Jeff KingApr 24, 2017
  33. Junio C HamanoApr 24, 2017
  34. Junio C HamanoApr 24, 2017
  35. Jeff KingApr 24, 2017
  36. Torsten BögershausenApr 24, 2017
  37. Jeff KingApr 24, 2017
  38. Junio C HamanoApr 25, 2017
  39. Junio C HamanoApr 25, 2017
  40. Jeff KingApr 25, 2017
  41. Junio C HamanoApr 25, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.