get process id

[Brian K. White]

Fairlight wrote:
> The honourable and venerable Kenneth Brody spoke thus:
>> Fairlight wrote:
>> [...]]
>>> Keeping in mind that the PID itself is not unique unless bound to a
>>> date and time, since PID-space recycles at around 32000-ish on most
>>> 32bit operating systems, and even some 64bit ones (Solaris 7 and 8
>>> come to mind).
>>
>> Well, it's unique during its lifetime.  Depending on the purpose,
>> this may be sufficient.
>
> May be.
>
>>> Ken, does USER directly exec() or does it use system()?
>>
>> system() and popen() don't allow the two-way pipe that USER needs, so
>> filePro uses fork()/exec() here.
>
> Good, then the USER to the perl one-liner will work fine.
>
> mark->

And, since I thought using perl just for that offended my sense of 
efficiency because the same thing is built-in in ksh and I thought ksh  just 
_has_ to be a lot lighter and faster to load & run than perl and besides 
that, every box, even really old boxes, clear back to Xenix, already has ksh 
and it's not so easy to get perl on some old sco boxes....

So I did a Stockler and came up with:

timeperl () {
  date
  n="1"
  until [ $n -ge 5000 ] ; do
    perl -e 'print(getppid(),"\n");' >/dev/null
    n=$((n+1))
    echo "${n}\r\c"
  done
  date
}

timeksh () {
  date
  n="1"
  until [ $n -ge 5000 ] ; do
    ksh 'echo $PPID' >/dev/null
    n=$((n+1))
    echo "${n}\r\c"
  done
  date
}


Before either run, top showed:
last pid: 19878;  load averages:  0.15,  0.10,  0.06 
17:59:29
130 processes: 117 sleeping, 12 zombie, 1 onproc
CPU states:  100% idle,  0.0% user,  0.0% system,  0.0% wait,  0.0% sxbrk
Memory: 1024M phys, 897M max, 830M free, 873M locked, K unlocked, K swap

just before the end of the perl run, top showed:
last pid: 24662;  load averages:  0.33,  0.14,  0.08 
18:00:39
125 processes: 110 sleeping, 2 running, 12 zombie, 1 onproc
CPU states:  0.0% idle, 43.2% user, 56.6% system,  0.2% wait,  0.0% sxbrk
Memory: 1024M phys, 897M max, 832M free, 873M locked, K unlocked, K swap

just before the end of the ksh run, top showed:
last pid: 29386;  load averages:  0.29,  0.15,  0.08 
18:01:29
125 processes: 110 sleeping, 2 running, 12 zombie, 1 onproc
CPU states:  0.0% idle, 26.4% user, 73.6% system,  0.0% wait,  0.0% sxbrk
Memory: 1024M phys, 897M max, 832M free, 873M locked, K unlocked, K swap

And the timings output from above were:
# timeperl
Sun Oct 10 18:00:16 EDT 2004
Sun Oct 10 18:00:40 EDT 2004
# timeksh
Sun Oct 10 18:01:14 EDT 2004
Sun Oct 10 18:01:31 EDT 2004

Note: the "before either" isn't _really_ before. I had run almost the same 
jobs a few times each already and so perl was already loaded into ram and 
probably not discareded yet. ksh will always be in ram since on my boxes 
lot's of scripts use it and it's roots login shell too. This is fine for 
this test though, since if the perl thing were implimented in the fp 
process, presumably it would get called all the time and so perl would 
always be in ram already then just as it is here. I wanted to test "would it 
cost more than necessary in a heavy use scenario where lots of users run a 
routine that calls this perhaps many times, perhaps even in loops, etc..." 
I'd say this fairly tests that case.

I'm quite nettled to have to admit I see little reason to avoid using perl 
for this other than the issue of simply _getting_ perl on old sco boxes. But 
in truth, if you are willing to accept older versions of perl, it's pretty 
easy even on older boxes as long as there is HD space (it winds up in / 
which many times has very little spare room and it's _bad_ when / gets full) 
and you have some way to get several megs of package files onto the box.

Brian K. White  --  brian at aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani