1 
function _abc {
:
1 min task
:
_check &
}

function _check {
wait for the previous calls of _check to complete
:
15 mins task
:
}

function abc loops depending on number of tasks. It is imperative that _check is backgrounded because function abc needs to keep on working and not wait for function check to complete

So basically, what I need is for the function check to be running one at a time and not all together. That is, the remaining calls of function check should be queued up and run one at a time once the previous one finishes.

Improve this question
4
  • Look into the use of wait which will block until any backgrounded children have terminated. Commented Feb 3, 2016 at 18:24
  • wait would be better but cant have it in function abc because i need it to keep on running also cant have it in check because how can it know the pid of the previous check Commented Feb 3, 2016 at 18:30
  • 1
    You can know the PID of the last backgrounded process, as it is stored in $!. You can also wait for a specific process to end with wait $PID (or, in this case, wait $!.) Commented Feb 3, 2016 at 18:32
  • 2
    @BrendenCarvalho pass the last _check's PID as an argument to _check. If no argument is given, start _check directly, or wait accordingly. Commented Feb 3, 2016 at 18:38

1 Answer 1

Reset to default
4

Go's idea of channels can be used here:

mkfifo my_pipe
exec 3<>my_pipe
trap 'rm my_pipe' EXIT
printf a >&3
function _abc {
    ...
    _check &
}

function _check {
    until read -N1 -u3; do :; done
    ...
    printf a >&3
}

Essentially:

  1. Create a named pipe for communicating between instances of _abc and _check.
  2. Have _check block on a read from the pipe (one byte in the example).
  3. Start off the first _check by printing a character (doesn't matter which) to the pipe. This should perhaps done outside the function if it loops.
  4. Have each _check instance write back to the pipe on exit.

To avoid writes to the pipe blocking, I added the pipe as an open file descriptor the shell (see https://unix.stackexchange.com/a/164295/70524). Also, if multiple reads are queued up on the same pipe, and one of the succeeds leaving the pipe empty, the others will report EOF. To overcome this, we have to loop on read until it succeeds in reading.

Improve this answer
13
  • If you're not cleaning up my_pipe, this will fail on any subsequent executions; I would add a trap 'rm my_pipe' EXIT to this. Commented Feb 3, 2016 at 18:25
  • this is awesome :) Commented Feb 3, 2016 at 18:28
  • read has a built-in timeout, but you'd need to know the theoretical maximum runtime so that you don't have a false timeout, causing a desync. Commented Feb 3, 2016 at 18:30
  • The idea of channels doesn't really translate. The more I think of it, the more holes I see in this. :/ Commented Feb 3, 2016 at 18:33
  • 1
    This is the first time I think I've seen a named pipe used bidirectionally. In theory, it should work, but, if you'll forgive the metaphor, pipes are easy to clog when you do this. Commented Feb 3, 2016 at 18:47

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.