IPC с именованными каналами: восстановление устаревшего кода

#fortran #ipc #named-pipes #legacy-code #fortran2003

#fortran #ipc #именованные каналы #устаревший код #fortran2003

Вопрос:

Я разрабатываю код на Fortran2003, который существенным образом зависит от выходных данных большой, сложной и очень эффективной унаследованной программы, написанной на Fortran77. Для будущего развития нового проекта было бы полезно, чтобы устаревшая программа не передавала данные путем создания больших файлов перед запуском новой программы, а предоставляла данные по запросу, в режиме реального времени, на основе запросов от новой программы. Из всех различных механизмов IPC, которые я видел, похоже, что именованные каналы было бы проще всего реализовать, что можно сделать с использованием встроенных функций Fortran, и что это также было бы прилично быстро (конечно, намного быстрее, чем обмен данными через реальные файлы!)

Я протестировал идею с двумя исполняемыми файлами, которые открывают один и тот же fifo в потоковом доступе, и, похоже, все работает нормально:

 program Proc1

  implicit none

  character(len=*), parameter :: DATA_FIFO ="data.fifo"
  integer            :: i, data_uid
  integer, parameter :: N = 100000000
  real(kind(1d0))    :: mat(N)

  open(newunit=data_uid,file=DATA_FIFO,access="stream")
  mat=1.d0
  write(*,*) "sending data",sum(mat)
  write(data_uid) (mat(i),i=1,N)
  close(data_uid)

end program Proc1
 
 program Proc2
  
  implicit none

  character(len=*), parameter :: DATA_FIFO ="data.fifo"
  integer            :: i, data_uid
  integer, parameter :: N = 100000000
  real(kind(1d0))    :: mat(N)

  open(newunit=data_uid,file=DATA_FIFO,access="stream")
  read(data_uid) (mat(i),i=1,N)
  write(*,*)"data received", sum(mat)
  close(data_uid)

end program Proc2
 

В реальном случае я бы изменил устаревший код, чтобы сделать его «демоном», способным прослушивать канал команд и считывать / записывать информацию в каналы данных, открытые с помощью новой программы. Когда новая программа будет масштабироваться до распределенной памяти, у каждого узла может быть свой собственный демон. Однако, прежде чем двигаться дальше, я хотел бы получить обратную связь о том, является ли эта схема вообще обоснованной идеей. Если ответ положительный, существуют ли стандартные реализации для этой проблемы (а именно, IPC между устаревшим кодом Fortran, преобразованным ad-hoc на сервер, и новым кодом fortran, который должен идти параллельно)? Если ответ отрицательный, каким было бы более правильное решение, которое может быть достаточно общим, не становясь очень сложным (совместное использование памяти выглядит сложным для меня)?
Большое вам спасибо за ваши мысли.

Комментарии:

1. Я здесь совсем не эксперт, но я предполагаю, что у вас, вероятно, будет некоторая зависимость от ОС — итак, какие ОС вас интересуют?

2. Unix (Linux или macOS 10), обычно на процессоре x86.

3. Именованные каналы будут работать до тех пор, пока все находится на одном компьютере. Если это может в конечном итоге стать распределенной системой, тогда, возможно, лучше использовать сокеты.

4. Имейте в виду, что отсутствие способа создания промежуточных наборов файлов данных может сильно затруднить диагностику ошибок и проблем

5. @Cocofalco безусловно, отсутствие диагностики было бы проблемой. Однако понятно, что IPC fifo предназначен для производства. Необходимо будет отдельно протестировать ввод-вывод двух программ. Во всяком случае, тестирование облегчается таким простым интерфейсом (две инструкции и два канала передачи данных) по сравнению с объединением двух кодов, поскольку две группы, которые их поддерживают, могут запускать свои тесты независимо, на основе четко определенного API. Также легко сбрасывать переданные данные в форматированные файлы журналов для целей отладки, когда две программы связаны вместе.