LINUX.ORG.RU

Если серьезно, fork или что-то еще? Ruby

 


0

1

Незнаю поможете или нет, но хотелось бы надеяться.

- Есть скрипт (демон) в вечном цикле - Скрит плодит fork

Вопрос какими средствами обратиться к поражденным fork-процессам а точнее к каждому? Кроме возвращаемого pid fork-а у меня получаеться ничего нет(

Ну, можно воспользоваться встроенным druby, к примеру:

require 'drb/drb'
require 'ostruct'

child_pid = fork do
  o = OpenStruct.new message: 'message'
  DRb.start_service "druby://localhost:#{Process.pid}", o
  sleep # if a main thread doesn't fell asleep, the child will exit
end

sleep 0.5 # wait while a druby service becomes available 
o = DRbObject.new_with_uri "druby://localhost:#{child_pid}"
p o.message

Anatolik ★★ ()
Ответ на: комментарий от Anatolik

Спасибо!

Получается механизм взаимодействия осуществлен через TCPSocket?
Если так, то - как на Ваш взгляд не эффективнее ли использовать UDPSoket? И еще есть такая штука как UNIXSocket, но есть одно но - в книге Флагмана описывается множественное соединение по TCPSocket через метод ядра select. Вопрос можно ли по аналогии применить это к UNIXSocket и к UDPSoket? И еще есть идея производить обмен данными между процессами через файлы файловой системы смонтированной в ОП. Будет ли это быстрее чем СОКЕТЫ? Или я несу ересь?)

beerdy ()
Ответ на: Спасибо! от beerdy

Если так, то - как на Ваш взгляд не эффективнее ли использовать UDPSoket?

А за потерями пакетов и порядком в котором они пришли кто будет следить? В TCP это предоставляется самим протоколом.

обмен данными между процессами через файлы файловой системы смонтированной в ОП

А почему не через разделяемую память? Зачем еще ФС поверх городить?

hidden_4003 ()
Ответ на: комментарий от hidden_4003

Спасибо!

Если не сложно, покажите пример как это делается? Я просто не в курсе(

beerdy ()
Ответ на: комментарий от exception13

longpool

1) Есть N-ое количество ассоциативных массивов (назовем их процессами) которые в виде fork или fiber или thread - порождаются Шелдером, при обращение к Шелдеру клиента.

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

3) Далее если клиент обратиться сново к Шелдеру, то задача Шелдера отдать метку клиенту - мол вот тебе ID процесса порожденного для тебя(клиента) при прошлом обращение ко мне (Шелдеру) иди и соединяйся со своим процессом а от меня отвали.

4) Далее клиент соединяется уже напрямую с процессом созданным для него. Если же Шелдер не находит процесс соответствующий клиенту то снова пункт 1)

beerdy ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.