Использование именованных каналов с bash-проблемой потери данных

как сказано в других ответах, вам нужно держать fifo открытым все время, чтобы избежать потери данных.

однако, как только все писатели ушли после того, как fifo был открыт (так что был писатель), читает возвращение немедленно (и poll() возвращает POLLHUP). Единственный способ очистить это состояние-снова открыть fifo.

POSIX не предоставляет решения для этого, но, по крайней мере, Linux и FreeBSD делают: если чтение начинается с сбоя, снова откройте fifo, сохраняя исходный дескриптор открыть. Это работает, потому что в Linux и FreeBSD состояние "зависания" локально для конкретного описания открытого файла, в то время как в POSIX оно глобально для fifo.

Это можно сделать скрипт вроде этого:

while :; do
    exec 3<tmp/testfifo
    exec 4<&-
    while read x; do
        echo "input: $x"
    done <&3
    exec 4<&3
    exec 3<&-
done

как camh & Деннис Уильямсон говорят, Не ломайте трубу.

Теперь у меня есть меньшие примеры, прямо в командной строке:

сервер:

(
  for i in {0,1,2,3,4}{0,1,2,3,4,5,6,7,8,9};
  do
    if read s;
      then echo ">>$i--$s//";
    else
      echo "<<$i";
    fi;
  done < tst-fifo
)&

клиент:

(
  for i in {%a,#b}{1,2}{0,1};
  do
    echo "Test-$i" > tst-fifo;
  done
)&

может заменить ключевую строку на:

    (echo "Test-$i" > tst-fifo&);

все данные клиента, отправленные в канал, считываются, хотя с опцией два клиента может потребоваться запустить сервер пару раз, прежде чем все данные будут считаны.

но хотя чтение ждет данных в труба для начала, как только данные были перемещены, она читает пустую строку навсегда.

любой способ остановить это?

Спасибо за любые идеи еще раз.

только для тех, кто может быть заинтересован, [[повторно отредактировано]] после комментариев camh и jilles, вот две новые версии сценария тестового сервера.

обе версии теперь работают точно так, как надеялись.

версия camh для управления трубой:

function jqs    # Job queue manager
{
  pipe=/tmp/__job_control_manager__
  trap "rm -f $pipe; exit"  EXIT TERM

  if [[ ! -p "$pipe" ]]; then
      mkfifo "$pipe"
  fi

  while true
  do
    if read -u 3 txt
    then
      echo "$(date +'%Y'): new text is [[$txt]]"

      if [[ "$txt" == 'quit' ]]
      then
    break
      else
        sleep 1
        # process $txt - remember that if this is to be a spawned job, we should close fd 3 and 4 beforehand
      fi
    fi
  done 3< "$pipe" 4> "$pipe"    # 4 is just to keep the pipe opened so any real client does not end up causing read to return EOF
}

версия jille для управления трубами:

function jqs    # Job queue manager
{
  pipe=/tmp/__job_control_manager__
  trap "rm -f $pipe; exit"  EXIT TERM

  if [[ ! -p "$pipe" ]]; then
      mkfifo "$pipe"
  fi

  exec 3< "$pipe"
  exec 4<&-

  while true
  do
    if read -u 3 txt
    then
      echo "$(date +'%Y'): new text is [[$txt]]"

      if [[ "$txt" == 'quit' ]]
      then
    break
      else
        sleep 1
        # process $txt - remember that if this is to be a spawned job, we should close fd 3 and 4 beforehand
      fi
    else
      # Close the pipe and reconnect it so that the next read does not end up returning EOF
      exec 4<&3
      exec 3<&-
      exec 3< "$pipe"
      exec 4<&-
    fi
  done
}

спасибо всем за помощь.

С одной стороны, проблема хуже, чем я думал: Теперь, кажется, есть случай в моем более сложном примере (jq_manage), когда одни и те же данные читаются снова и снова из канала (даже если в него не записываются новые данные).

С другой стороны, я нашел простое решение (редактировать следующий комментарий Денниса):

function jqn    # compute the number of jobs running in that group
{
  __jqty__=$(jobs | egrep "Running.*echo '%#_Group_#%_$__groupn__'" | wc -l)
}

function jq
{
  __groupn__="";  shift   # job group name (the pool within which to allocate $__jmax__ jobs)
  __jmax__="";    shift   # maximum of job numbers to run concurrently

  jqn
  while (($__jqty__ '>=' $__jmax__))
  do
    sleep 1
    jqn
  done

  eval "(echo '%#_Group_#%_$__groupn__' > /dev/null; $@) &"
}

работает как шарм. Ни розетки, ни трубы. Простой.

выполнить не более 10 заданий параллельно и поставить остальные в очередь для последующей обработки, но надежно знать, что они выполняются

вы можете сделать это с помощью GNU Parallel. Вам не понадобится этот сценарий.

http://www.gnu.org/software/parallel/man.html#options

вы можете установить max-procs " количество рабочих мест. Запуск до N заданий параллельно."Есть вариант установить количество ядер процессора, которые вы хотите использовать. Вы можете сохранить список выполненных заданий в файл журнала, но это бета-функция.