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

Re: [PATCH v2] fsmonitor OSX: fix hangs for submodules

From
Koji Nakamaru <koji.nakamaru@gree.net>
Date
Oct 1, 2024, 18:42 UTC
Message-ID
<CAOTNsDz=gV1TQ=N+8V+CdhWkPSogNM-42B+vzhDNWdM-Wz9CfQ@mail.gmail.com>
In-Reply-To
<xmqqmsjnya1c.fsf@gitster.g>
On Wed, Oct 2, 2024 at 3:04 AM Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
>>> > +test_expect_success "submodule implicitly starts daemon by pull" '
>>> > + test_atexit "stop_watchdog" &&
>>> > + test_when_finished "stop_git && rm -rf cloned super sub" &&
>>>
>>> If stop_git ever returns with non-zero status, "rm -rf" will be
>>> skipped, which I am not sure is a good idea.
>>>
>>> The whole test_when_finished would fail in such a case, so you would
>>> notice the problem right away, which is a plus, though.
>>
>> t/README discusses that test_when_finished and test_atexit differ about
>> the "--immediate" option. As git and its subprocesses are the test
>> target, I moved stop_git to the current place. This might be however
>> confusing when someone later reads this test. Should we simply put
>> stop_git and stop_watchdong in test_atexit?
>
> That is not what I meant.
>
> I was merely questioning the &&-chaining that stops "rm -fr" from
> running if stop_git ever fails (and your earlier iteration you had
> multiple "rm -fr" ;-chained, not &&-chained---not using && is often
> more appropriate in a when_finished handler).
I see. I'll fix this part.
Show 22 quoted lines
>>> > + set -m &&
>>>
>>> I have to wonder how portable (and necessary) this is.
>>>
>>> POSIX says it shall be supported if the implementation supports the
>>> User Portability Utilities option.  It also says that it was added
>>> to apply only to the UPE because it applies primarily to interactive
>>> use, not shell script applications.  And our test scripts are of
>>> course not interactive.
>>
>> How about the following modification? It still utilizes $git_pgid to
>> filter processes, but avoids "set -m".
>
> Nah, your original reads much better, and the code is grabbing and
> using the process group information anyway (and my question about
> "-m" was more about "should we be relying on process group features
> in this test to kill them all?").
>
> I am OK with the idea that we can assume, at least among the
> platforms that support fsmonitor, that sending a signal to a process
> group would cause the signal delivered to the member processes just
> as we expect.
Thank you for the clarification and the support.
Koji Nakamaru
Previous: Junio C HamanoNext: Koji Nakamaru
Message 8 of 19 in “fsmonitor OSX: fix hangs for submodules”
  1. fsmonitor OSX: fix hangs for submodulesKoji Nakamaru via GitGitGadget, Sep 29, 2024
  2. Junio C HamanoSep 30, 2024
  3. Koji NakamaruOct 1, 2024
  4. fsmonitor OSX: fix hangs for submodulesKoji Nakamaru via GitGitGadget, Oct 1, 2024
  5. Junio C HamanoOct 1, 2024
  6. Koji NakamaruOct 1, 2024
  7. Junio C HamanoOct 1, 2024
  8. Koji NakamaruOct 1, 2024
  9. Koji NakamaruOct 2, 2024
  10. Junio C HamanoOct 2, 2024
  11. Koji NakamaruOct 3, 2024
  12. Junio C HamanoOct 3, 2024
  13. Koji NakamaruOct 4, 2024
  14. fsmonitor OSX: fix hangs for submodulesKoji Nakamaru via GitGitGadget, Oct 1, 2024
  15. fsmonitor OSX: fix hangs for submodulesKoji Nakamaru via GitGitGadget, Oct 4, 2024
  16. Junio C HamanoOct 4, 2024
  17. Ramsay JonesOct 4, 2024
  18. Junio C HamanoOct 4, 2024
  19. Koji NakamaruOct 5, 2024

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.