From: Junio C Hamano <gitster@pobox.com>
To: "Koji Nakamaru via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Koji Nakamaru <koji.nakamaru@gree.net>
Subject: Re: [PATCH v2] fsmonitor OSX: fix hangs for submodules
Date: Tue, 01 Oct 2024 04:57:00 -0700 [thread overview]
Message-ID: <xmqqwmis11f7.fsf@gitster.g> (raw)
In-Reply-To: <pull.1802.v2.git.1727759371110.gitgitgadget@gmail.com> (Koji Nakamaru via GitGitGadget's message of "Tue, 01 Oct 2024 05:09:30 +0000")
"Koji Nakamaru via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: Koji Nakamaru <koji.nakamaru@gree.net>
>
> fsmonitor_classify_path_absolute() expects state->path_gitdir_watch.buf
> has no trailing '/' or '.' For a submodule, fsmonitor_run_daemon() sets
> the value with trailing "/." (as repo_get_git_dir(the_repository) on
> Darwin returns ".") so that fsmonitor_classify_path_absolute() returns
> IS_OUTSIDE_CONE.
>
> In this case, fsevent_callback() doesn't update cookie_list so that
> fsmonitor_publish() does nothing and with_lock__mark_cookies_seen() is
> not invoked.
>
> As with_lock__wait_for_cookie() infinitely waits for state->cookies_cond
> that with_lock__mark_cookies_seen() should unlock, the whole daemon
> hangs.
>
> Remove trailing "/." from state->path_gitdir_watch.buf for submodules
> and add a corresponding test in t7527-builtin-fsmonitor.sh.
>
> Suggested-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> Suggested-by: Junio C Hamano <gitster@pobox.com>
In none of the changes described above, I have any input to deserve
such credit, though.
> +start_git_in_background () {
> + git "$@" &
> + git_pid=$!
> + git_pgid=$(ps -o pgid= -p $git_pid)
> + nr_tries_left=10
> + while true
> + do
> + if test $nr_tries_left -eq 0
> + then
> + kill -- -$git_pgid
> + exit 1
> + fi
> + sleep 1
> + nr_tries_left=$(($nr_tries_left - 1))
> + done >/dev/null 2>&1 &
> + watchdog_pid=$!
> + wait $git_pid
> +}
> +
> +stop_git () {
> + while kill -0 -- -$git_pgid
> + do
> + kill -- -$git_pgid
> + sleep 1
> + done
> +}
On the "git" side you use process group because you expect that
"git" would spawn subprocesses and you want to catch all of them,
...
> +stop_watchdog () {
> + while kill -0 $watchdog_pid
> + do
> + kill $watchdog_pid
> + sleep 1
> + done
> +}
... but "watchdog" you know is a single process, so you'd only need
a single process id, is that the idea?
What is the motivation behind the change in this iteration to use
process group? Was it observed that leftover processes hang around
if we killed only the $git_pid, or something?
> +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.
> + create_super super &&
> + create_sub sub &&
> +
> + git -C super submodule add ../sub ./dir_1/dir_2/sub &&
> + git -C super commit -m "add sub" &&
> + git clone --recurse-submodules super cloned &&
> +
> + git -C cloned/dir_1/dir_2/sub config core.fsmonitor true &&
> + 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.
Thanks.
next prev parent reply other threads:[~2024-10-01 11:57 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-29 2:41 [PATCH] fsmonitor OSX: fix hangs for submodules Koji Nakamaru via GitGitGadget
2024-09-30 17:40 ` Junio C Hamano
2024-10-01 4:11 ` Koji Nakamaru
2024-10-01 5:09 ` [PATCH v2] " Koji Nakamaru via GitGitGadget
2024-10-01 11:57 ` Junio C Hamano [this message]
2024-10-01 17:51 ` Koji Nakamaru
2024-10-01 18:04 ` Junio C Hamano
2024-10-01 18:42 ` Koji Nakamaru
2024-10-02 6:58 ` Koji Nakamaru
2024-10-02 18:14 ` Junio C Hamano
2024-10-03 8:54 ` Koji Nakamaru
2024-10-03 17:44 ` Junio C Hamano
2024-10-04 2:42 ` Koji Nakamaru
2024-10-01 19:29 ` [PATCH v3] " Koji Nakamaru via GitGitGadget
2024-10-04 0:07 ` [PATCH v4] " Koji Nakamaru via GitGitGadget
2024-10-04 17:44 ` Junio C Hamano
2024-10-04 18:47 ` Ramsay Jones
2024-10-04 19:07 ` Junio C Hamano
2024-10-05 3:12 ` Koji Nakamaru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqwmis11f7.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=koji.nakamaru@gree.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).