From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Michael Witten <mfwitten@gmail.com>,
Junio C Hamano <gitster@pobox.com>,
git@vger.kernel.org, David Barr <david.barr@cordelta.com>
Subject: Re: [PATCH] Portability: returning void
Date: Tue, 29 Mar 2011 18:36:18 -0400 [thread overview]
Message-ID: <20110329223618.GC23510@sigill.intra.peff.net> (raw)
In-Reply-To: <20110329221652.GB23510@sigill.intra.peff.net>
On Tue, Mar 29, 2011 at 06:16:52PM -0400, Jeff King wrote:
> On Tue, Mar 29, 2011 at 03:02:48PM -0500, Jonathan Nieder wrote:
>
> > Next step is to figure out the longstanding mysterious bash + prove
> > hang in t0081.
>
> [...]
>
> 2. Tests should kill their backgrounded sleeps themselves. I think I
> saw some "kill $!" lines in there, but maybe we are missing one.
Indeed, those kill lines aren't doing what you expect. Try instrumenting
like this:
diff --git a/t/t0081-line-buffer.sh b/t/t0081-line-buffer.sh
index 1dbe1c9..3b2f8ce 100755
--- a/t/t0081-line-buffer.sh
+++ b/t/t0081-line-buffer.sh
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
test_description="Test the svn importer's input handling routines.
@@ -56,6 +56,7 @@ long_read_test () {
binary $readsize
copy $copysize
EOF
+ echo >>/tmp/foo killing $!
kill $! &&
test_line_count = $lines output &&
tail -n 1 <output >actual &&
@@ -90,6 +91,7 @@ test_expect_success PIPE '0-length read, no input available' '
binary 0
copy 0
EOF
+ echo >>/tmp/foo killing $!
kill $! &&
test_cmp expect actual
'
@@ -119,6 +121,7 @@ test_expect_success PIPE '1-byte read, no input available' '
binary 1
copy 1
EOF
+ echo >>/tmp/foo killing $!
kill $! &&
test_cmp expect actual
'
And then run the test under prove, and check "ps" for remaining sleep
processes. You will see that the killed process IDs do not match up with
the sleep processes. Except for one sleep process, which actually got
killed. That is the second one in the list above. It works because it's:
{
sleep 100 >input &
} &&
...
kill $!
whereas the other ones are like:
{
do_something &&
sleep 100
} >input &
So my guess is that we have to start a subshell for the latter ones, and
_that_ is what gets killed. And that may explain the bash vs dash
behavior; dash, upon receiving the kill signal, presumably kills its
child, but bash does not (I didn't confirm that; it's just a theory).
I'm not sure what the best solution is. Perhaps putting the subshell
into its own process group and killing the whole PGRP?
-Peff
next prev parent reply other threads:[~2011-03-29 22:36 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-29 17:31 [PATCH] Portability: returning void Michael Witten
2011-03-29 20:02 ` Jonathan Nieder
2011-03-29 22:16 ` Jeff King
2011-03-29 22:36 ` Jeff King [this message]
2011-03-29 23:49 ` Jonathan Nieder
2011-03-30 0:16 ` Jeff King
2011-03-30 0:29 ` Jonathan Nieder
2011-03-30 3:30 ` Jeff King
2011-03-30 3:57 ` Jonathan Nieder
2011-03-30 4:13 ` Jeff King
2011-03-30 6:54 ` Johannes Sixt
2011-03-30 8:16 ` [PATCH/RFC svn-fe] tests: introduce helper to fill a pipe in the background Jonathan Nieder
2011-03-30 8:41 ` [PATCH] Portability: returning void Jonathan Nieder
2011-03-30 12:40 ` Jeff King
2011-03-30 18:54 ` Jonathan Nieder
2011-03-30 4:41 ` [PULL svn-fe] " Jonathan Nieder
2011-03-30 19:31 ` Junio C Hamano
2011-03-30 0:42 ` [PATCH] " Jonathan Nieder
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=20110329223618.GC23510@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=david.barr@cordelta.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=mfwitten@gmail.com \
/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).