с помощью Kernel#fork для процессов фоновой обработки, профессионалов? недостатки?

Форк действительно делает копию всего вашего процесса, и, в зависимости от того, как именно вы подключены к серверу приложений, копию этого процесса. Как отмечалось в другом обсуждении, это делается с помощью копирования при записи , поэтому это допустимо. В конце концов, Unix построен на основе fork (2), поэтому он должен управлять им довольно быстро. Обратите внимание, что любой частично буферизованный ввод-вывод, открытые файлы и многое другое также копируются, как и состояние программы, которая подпружинена для их записи, что было бы неверно.

У меня есть несколько мыслей:

• Вы используете Action Mailer? Похоже, что электронную почту можно было бы легко сделать с помощью AM или Process.popen чего-то. (Popen выполнит форк, но сразу за ним следует exec.)
• немедленно избавьтесь от всего этого состояния, выполнив Process.exec другого интерпретатора ruby ​​плюс ваши функции. Если слишком много состояния для передачи или вам действительно нужно использовать эти дублированные файловые дескрипторы, вы можете вместо этого сделать что-то вроде IO # popen , чтобы вы могли отправить подпроцесс для выполнения работы. Система автоматически поделится страницами, содержащими текст Ruby-интерпретатора подпроцесса, с родительским процессом.
• в дополнение к вышесказанному, вы можете рассмотреть возможность использования гемов . Хотя ваш процесс rails уже является демоном, использование драгоценного камня может упростить выполнение одной фоновой задачи в качестве сервера пакетных заданий, а также упростить запуск, мониторинг, перезапуск, если он взорвался, и выключение, когда вы это сделаете ...
• если вы действительно выйдете из подпроцесс fork (2) ed, используйте exit! вместо exit
• с уже настроенной очередью сообщений и демоном, как и вы, звучит как хорошее решение для меня: -)

Имейте в виду, что это помешает вам использовать JRuby on Rails, поскольку fork () не реализован (пока).

Семантика fork состоит в том, чтобы скопировать все пространство памяти процесса в новый процесс, но многие (большинство?) Систем будут делать это, просто копируя таблицы виртуальной памяти и маркировка копирования при записи. Это означает, что (по крайней мере на первых порах) он не использует столько физической памяти, сколько достаточно для создания новых таблиц и других структур данных для каждого процесса.

Тем не менее, я не уверен, насколько хорошо Ruby , RoR и т. Д. Взаимодействуют с разветвлением копирования при записи. В частности, сборка мусора может быть проблематичной, если она затрагивает многие страницы памяти (вызывая их копирование).