lkml.org 
[lkml]   [1999]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: fork or exec thingy.
In <Pine.LNX.4.10.9907221707240.13890-100000@ps.cus.umist.ac.uk> Riley Williams (rhw@MemAlpha.CX) wrote:
> Hi Terje.

>> Bash on Linux seems to have problems starting subprocesses
>> occasionally, the following program fails randomly:

>> #!/bin/bash
>> printf %5d 2
>> i=3
>> while /usr/bin/test $i -lt 10000 ; do
>> j=3
>> while /usr/bin/test $j -lt $i ; do
>> if /usr/bin/test `expr $i % $j` -eq 0 ; then
>> j=$i
>> fi
>> j=`expr $j + 2`
>> done
>> if /usr/bin/test $j -eq $i ; then
>> printf %5d $i
>> fi
>> i=`expr $i + 2 `
>> done

>> typical output:
>>
>> # sh primes.sh
>> 2 3 5 7 11 13 17 19 23 29 31 37 41 43 47 53 59 61 67 71 73 79 83 89 97 101 103 107 109 113 127 131 137 139 149 151 157 163 167 173 179 181 191 193 197 199 211 223 227 229 233 239 241 251 257 263 269 271 277 281 283 293 307 311 313 317 331 337 347 349 353 359 367 373 379 383 389 397 401 409 419 421 431 433 439 443 449 457 461 463 467 479 487 491 499 503 509 521 523 541 547
> 557 563 569 571 577 587 593 599 601 607 613 617 619 631 641 643 647 653 659 661 673 677 683 691 701 709 719 727 733 739 743 751 757 761 769 773 787 797 809 811 821 823 827 829 839 853 857 859primes.sh: Can't reopen pipe to command substitution (fd 4): No child processes
>> /usr/bin/test: argument expected
>> /usr/bin/test: argument expected
>> primes.sh: Can't reopen pipe to command substitution (fd 4): No child processes
>> /usr/bin/test: argument expected
>> 877 881 883 887 907 911 919 929 937 941 947 953 967 971 977 983

> Note that those errors are NOT bash errors, but errors from the
> separate test program that you're calling.

Huh.
-- cut --
primes.sh: Can't reopen pipe to command substitution (fd 4): No child processes
-- cut --
is clearly comes from bash itself.

> That also leads to the obvious question: Why use an external test
> program when bash has a faster one built in to it?

Are you REALLY THAT dumb ? The whole idea of test was to check bash's ability
to spawn external commands. Version without them will be faster, no problem.
But with such "improvement" the whole idea of initial test is lost :-((



> Here's the above script, with a common tweak to enable it to process the
> larger numbers faster, and written to use bash's internal test command instead...

> ===8<=== CUT ===>8===
> #!/bin/bash
> printf %5d 2
> declare -i i=3 j k=1 l
> while [ $i -lt 10000 ]; do
> j=3
> l=`echo 2k$i v0.5+p | dc | cut -d . -f 1`
> while [ $j -le $l ]; do
> if [ $[$i%$j] -eq 0 ]; then
> break
> fi
> j=$j+2
> done
> if [ $j -gt $l ]; then
> printf %5d $i
> k=$k+1
> if [ $k -eq 15 ]; then
> echo
> k=0
> fi
> fi
> i=$i+2
> done
> ===8<=== CUT ===>8===

> This version prints out the results much faster than yours does.

> Incidentally, the 'tweak' referred to above is to recognise that any
> number can only have a divisor greater than its square root if it also
> has one smaller than its square root, so the inner loop only tests up
> to and including the odd number nearest to the square root.

> As an example of the speedup involved, when it's checking 9973 for
> primality, it only needs to check for divisibility by one of 50
> numbers to determine that, rather than checking for divisibility by
> one of 4,986 numbers.

Greeaat optimization. If you need prime numbers. Not if you need test with lots
of process spawning. BTW if you REALLY need prime numbers then better just use
"C" and different algorith :-)

> Incidentally, it determines that 9973 is prime.

> Also, a second speedup is gained by moving the printing test outside
> of the inner loop, and a third by declaring all numeric variables to
> be numeric.

>> I've tested this on 2.2.6 2.2.6ac1 2.2.9 and 2.2.10ac10 with
>> bash versions 1.14 and 2.03. Machines tested were idle apart
>> from the shellscript, with plenty of RAM.

> This looks like a faulty test command to me - certainly, I was unable
> to get the script to fail...

If you was unable to get the YOUR script to fail and not initial script then
you basically tested wrong thing.

>> This does not happen on 2.0.36, nor does this happen in bash on
>> Solaris, Irix or Digital Unix.

> Not sure what the problem is, but it's neither a kernel one nor a bash
> one...

OF COURSE ! When you removed the only thing which was tested test will no
longer fail fail for sure!!!

Terje: It failed to walk.
Riley: Walk is sooo slow, let change it to fly. See ? No problems anymore...

P.S. Said this I must admit that I was unable to trigger problem with initial
script and kernel 2.2.2ac5, 2.2.5ac6 and 2.2.10ac10 here (under KSI-Linux 2.1
beta) so it really does not look like kernel problem...




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.988 / U:0.000 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site