a novel idea: a sh with a `fork built-in?

[TerryP]

whilst pushing a broom today, the following idea hit me:

# a super simple but conceptual example 

# a variable to communicate status between child/parent
fork ALIVE
if [ $? -eq -1 ]; then
    echo "$0: Unable to fork for ..., stopping $0"
    exit 255
elsif [ $? -ge 0 ]; then
    echo "doing processing: ... whatever"

    # when the child exits, the variable becomes false (and exits the loop)
    while [ $ALIVE ]; do
        echo '.'
    done
    echo 'done processing'
else
    do lengthy processing in child
    exit 1
fi

like so much other software out there, my tpsh does synchronous execution of external commands by way of fork()'ing, followed by a wait() in the parent and an exec() in the child. ('&', job control, '[', and control flow are not implemented yet)

Then I thought, well hell, if the shell can fork stuff all day and we can use the & to execute programs asynchronously and move on - why shouldn't shell script be able to access the fork system call directly through a shell built in command? Implementing it shouldn't be much harder then the &, [, and control/flow stuff that needs doing anyway, and to me it sounds like an interesting feature/extension.


I was wondering if anyone else had an opinion on this idea.

[robbak]

The big issue with this pseudo code is that you are busy-waiting on that $ALIVE variable: always a bad idea. While $ALIVE; do sleep(n); done would be better, but not much.
If this was done, you would need a separate function that waited on the jobs more efficiently than that busy waiting. A busy wait (Hmm, I hope that is the name for a hard loop like this(It is: Thanks wikipedia)) is the definition of inefficient programming.
I also am not sure if shell variables could be used in this way: the called program would have it's own environment, so $ALIVE in the calling process would remain untouched.
My syntax would look more like this.

jobid == fork $remote_program
exec $local_program
fork-wait $jobid

This (or something similar) could probably be done using current shell commands: & of a process, and check/wait on it's job number. (Maybe you'd have to do that with a busywait, though.

[TerryP]

I've rarely known super simple examples to display efficient programming practices ;-) (the example shouldn't even require a fork in some cases)

Originally Posted by robbak

I also am not sure if shell variables could be used in this way: the called program would have it's own environment, so $ALIVE in the calling process would remain untouched.

Aye, it would be a "forked" variable of sorts. The shell would execute the fork built in; fork itself and set the $ALIVE and $? variables accordingly within their process before reading the next line of the script; to the parent $ALIVE represents the child's status. When the parent receives SIGCHLD, it would change the value of $ALIVE so that the shell script would know it's kid finished, should it care.


The problem (in my sleep starved) mind at the moment, would be how to make tpsh go back from the signal handler to where it was (in the examples case, likely inside the while $ALIVE loop) before the child exited, and interrupted the script. Best guess that I can think of without sleeping on it, is things like the while loop and individual lines would need to block signals until the end of the loop/line has been handled by the shell, and then re-execute the appropriate function or something like that after getting SIGCHLD; which would have to know how to restore it's place form saved state. (which really does not sound like fun writing, come to think of it) And is probably easier to think about then write outside of asm, assuming I'm still thinking semi-clearly at this time of night/morning in the first place.

Either way... time for crashing to a pillow.

Originally Posted by robbak

My syntax would look more like this. ... This (or something similar) could probably be done using current shell commands: & of a process, and check/wait on it's job number. (Maybe you'd have to do that with a busywait, though.

it's possible to do an async launch&, and although I've never used it modern shells have a built-in wait [job] command for whatever it's actually worth; but afaik no way to execute 1 shell script in 2 processes at the same time, without using a temporary shared file/named pipe in some equally inefficient ways to coordinate them.


(For some reason, I think I'll be having multi-threaded nightmares >_<)

[ephemera]

Is this what you wanted to do?

#!/bin/sh

command="sleep 5"       # lengthy processing program
trap 'echo .; exit' TERM
printf "running \"$command\" ";
($command; printf " finished with exitcode=$?"; kill $$)&
while [ 1 ]; do printf .; sleep 1; done

[TerryP]

more or less yeah, that's the example case I was using ephemera.

As to your example, except if one doesn't want the parent to pop a cork when the sub shell closes, something like this might be more appropriate:

ALIVE=1
command="sleep 5"       # lengthy processing program
trap 'ALIVE=0' TERM
printf "running \"$command\" ";
($command; printf " finished with exitcode=$?\n"; kill $$)&
while [ $ALIVE -gt 0 ]; do printf .; sleep 1; done
echo continue with other work when child is done

you could say, the idea of a fork built in would be to say something like, "setup the trap for me"


or to rewrite the original (fork) example with trap:

# a super simple but conceptual example

# a variable to communicate status between child/parent
ALIVE=1
trap 'ALIVE=0' TERM

if [ $? -ne 0 ]; then
    # Note: if trap ever errors out beyond syntax errors
    #     I never check the exit status of trap in my
           own scripts
    echo "$0: Unable to trap SIGTERM for ..., stopping $0"
    exit 255
else
    echo "doing processing: ... whatever"

    (do lengthy processing in child; kill $$) &

    # when the child exits, the variable becomes false (and exits the loop)
    while [ $ALIVE -gt 0 ]; do
        printf '.'; sleep 1
    done
    echo 'done processing'
fi

(this reminds me, making key bindings in ksh93 is a fun)