On 6/28/06, George Boudreau <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote:
> On 6/28/06, George Boudreau <[EMAIL PROTECTED]> wrote:
>>
>> # note.. DO NOT try and trace the variable makePID..
>> # it changes the fuser text
>> makePID=$(fuser -v . 2>&1 | grep make)
>> makePID=$(echo $makePID | cut -d" " -f2)
>>
>> write_or_exit() {
>>
>> # make has been killed or failed or run to completion, leave
>> [[ ! -e /proc/$makePID ]] && echo -n "${CURSOR_ON}" && exit
>>
>> # Target build complete, leave.
>> [[ -f ${TARGET} ]] && echo -n "${CURSOR_ON}" && exit
>>
>> # It is safe to write to the screen
>> echo -n "$1"
>> }
I see you already checked this in, but I just wanted to confirm that
it works for me in the normal use case (root running ./lfs or make).
> Yes! Why didn't I think of that before? It's a little bit of a hack
> since that pid could be reused, but the chances of that happening in
> between write_or_exit pollings is obviously miniscule. Way better.
Actually the pid of make cannot be reused until 'make' terminates at
which point the progress_bar script dies of loneliness (no one to play
with). The progress_bar script normally exits when a target is
successfully built and the makefile touches nnn-target. The other test
is there to catch target build failures or makefile abnormal termination.
What I was thinking was this situation (and all its unlikeliness).
During the .12 seconds between invoking write_or_exit(), make has been
interrupted and another process has started and grabbed the same pid.
If progress_bar.sh is still running in the background, it passes both
of the tests on the next call of write_or_exit(). The ${makePID}
exists and $(TARGET) doesn't exist. It's a very minor race condition.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
