sleep 999 after tests

sleep 999 after tests

[Marijn Schouten]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

the two sleep 999's in test-suite/tests/popen.test are really annoying. Is
there any good reason for them to be there? The following patch alleviates the
issue:

- --- test-suite/tests/popen.test 2007-05-25 16:44:34.000000000 +0200
+++ newpopen    2007-05-25 16:56:09.000000000 +0200
@@ -82,7 +82,7 @@
           (port (with-error-to-port (cdr pair)
                   (lambda ()
                     (open-input-pipe
- -                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
sleep 999")))))
+                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
sleep 1")))))
       (close-port (cdr pair))   ;; write side
       (and (char? (read-char (car pair))) ;; wait for child to do its thing
           (char-ready? port)
@@ -132,7 +132,7 @@
              (port (with-error-to-port (cdr pair)
                      (lambda ()
                        (open-output-pipe
- -                        "exec 0</dev/null; echo closed 1>&2; exec
2>/dev/null; sleep 999")))))
+                        "exec 0</dev/null; echo closed 1>&2; exec
2>/dev/null; sleep 1")))))
         (close-port (cdr pair))   ;; write side
         (and (char? (read-char (car pair))) ;; wait for child to do its thing
              (catch 'system-error

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGVvnqp/VmCx0OL2wRAsMQAKCDRdQ6f/42vQdPB0Wyf7O0YGxF5QCcC7Ha
lSeyDsPfy5hgYEj+3UlJ8UI=
=9tdD
-----END PGP SIGNATURE-----


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: sleep 999 after tests

[Kevin Ryde]

[belated followup]

Marijn Schouten <M.Schouten@phys.uu.nl> writes:
>
> the two sleep 999's in test-suite/tests/popen.test are really annoying. Is
> there any good reason for them to be there?

Yep.  The parent process is supposed to see eof from the child, and in
normal operation it then continues.  If it blocks for the whole sleep
999 then something has gone wrong.

> -                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
> sleep 999")))))
> +                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
> sleep 1")))))

Alas, no, 1 second may not be long enough for the parent to notice what
the child has done, depending on system load etc.

(It may be possible to make a better test, but bear in mind there was an
actual bug in that area in the past, which the tests are trying to
ensure doesn't raise its ugly head again.)


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: sleep 999 after tests

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin Ryde wrote:
> [belated followup]
> 
> Marijn Schouten <M.Schouten@phys.uu.nl> writes:
>> the two sleep 999's in test-suite/tests/popen.test are really annoying. Is
>> there any good reason for them to be there?
> 
> Yep.  The parent process is supposed to see eof from the child, and in
> normal operation it then continues.  If it blocks for the whole sleep
> 999 then something has gone wrong.
> 
>> -                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
>> sleep 999")))))
>> +                     "exec 1>/dev/null; echo closed 1>&2; exec 2>/dev/null;
>> sleep 1")))))
> 
> Alas, no, 1 second may not be long enough for the parent to notice what
> the child has done, depending on system load etc.
> 
> (It may be possible to make a better test, but bear in mind there was an
> actual bug in that area in the past, which the tests are trying to
> ensure doesn't raise its ugly head again.)

This test depends on networking being enabled. If networking is disabled it
should preferably not run at all, but if it runs it should fail in an
acceptable amount of time. So how about making it 30 seconds?

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxVhZp/VmCx0OL2wRApccAJ47fObzedfgMgpRyTmboWtt2oWvLQCeL3QZ
YJNKo1E0lcjbuRXxCE16RqU=
=BLHM
-----END PGP SIGNATURE-----


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: sleep 999 after tests

[Ludovic Courtès]

Hi,

"Marijn Schouten (hkBst)" <hkBst@gentoo.org> writes:

> This test depends on networking being enabled.

Then we should just make the test conditional, using `(provided?
'socket)'.

BTW, why is networking disabled in Gentoo builds?

Thanks,
Ludovic.




_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: sleep 999 after tests

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ludovic � wrote:
> Hi,
>
> "Marijn Schouten (hkBst)" <hkBst@gentoo.org> writes:
>
>> This test depends on networking being enabled.
>
> Then we should just make the test conditional, using `(provided?
> 'socket)'.
>
> BTW, why is networking disabled in Gentoo builds?

It's not disabled, it's optional.

I am merely exposing this configure option.

- --
Marijn Schouten (hkBst), Gentoo Lisp project
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGxaGsp/VmCx0OL2wRAhwrAJ4nz9MeIFv39RBFGAdlUNlPHUcalwCeKHCU
8GquwlEeDaaDI8OoM/+TzFY=
=pbeS
-----END PGP SIGNATURE-----


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile

Re: sleep 999 after tests

[Kevin Ryde]

"Marijn Schouten (hkBst)" <hkBst@gentoo.org> writes:
>
> This test depends on networking being enabled.

Does it?  It's a pipe, not a socket.

> So how about making it 30 seconds?

No, but something that made the two processes watch more closely what
each other is doing would be fine.  (I suppose the child process ought
to be killed+waited explicitly too.)

As I said though, if it's blocking for 999 then you're looking at a bug,
maybe in guile, maybe in the test.


_______________________________________________
Bug-guile mailing list
Bug-guile@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-guile