как бы сделали вы?

← →
Поросенок Винни-Пух © (2008-06-07 16:28) [0]

Есть процесс, который в силу некоторых объективных по отношению к нему причин не может работать с разными сущностями, порожденными из одного и того же шаблона.
Процесс этот не интеракивный, обслуживает клиентов в многопоточном режиме и поэтому перегружать (даже автоматом) не представляется возможным (без того, чтобы не произошел отказ в обслуживании или его задержка). Принято решение вынести функционал по работе с сущностями в отдельные процессы, которые будут запускаться из клиентских ниток.

Как бы вы сделали двусторонний обмен данными между ниткой главного процесса и вспомогательным процессом?

Информация, которой необходимо обмениваться - это блоки памяти произвольного размера. Скажем так, что в основном это сотни килобайт. иногда до десяти-пятнадцати мегабайт

← →
ketmar © (2008-06-07 16:30) [1]

натурально, на unix sockets.

---
Understanding is not required. Only obedience.

← →
Поросенок Винни-Пух © (2008-06-07 16:37) [2]

1. платформа - винда.
2. вспомогательные процессы должны быть именно процессами, иначе получится тот же облом. То есть от мультиплексирования тсп соединений во вспомогательном процессе придется отказаться и заморачиваться распределением номеров слушающих портов.

← →
ketmar © (2008-06-07 16:39) [3]

>[2] Поросенок Винни-Пух © (2008-06-07 16:37:00)
>1. платформа - винда.
ССЗБ. накладные расходы на запуск процесса на винде таковы, что это попросту глупо.

---
Understanding is not required. Only obedience.

← →
Поросенок Винни-Пух © (2008-06-07 16:41) [4]

глупо это если не будет работать вообще.
а в одном процессе не будет.

← →
Игорь Шевченко © (2008-06-07 16:42) [5]

> Как бы вы сделали двусторонний обмен данными между ниткой
> главного процесса и вспомогательным процессом?

Я бы сделал N процессов (или сервисов) (по количеству обрабатываемых в одном процессе сущностей), запускал бы их по первому приходу обрабатываемой сущности и не убивал бы. Ну а дальше любой обмен - пайпы, файлы, сокеты

← →
Поросенок Винни-Пух © (2008-06-07 16:43) [6]

накладные расходы мне не важны.
там 16 ядер на четырех зионах

← →
Поросенок Винни-Пух © (2008-06-07 16:47) [7]

неубиваемые вторичные это скорее всего лишнее.
точное N неизвестно, и растет со временем.
а в основном процессе нити создаются только непосредственно для обслуживания клиента. а клиенты работают с системой без постоянного тсп соединения (транспортный протокол там http )

← →
ketmar © (2008-06-07 17:33) [8]

>[6] Поросенок Винни-Пух © (2008-06-07 16:43:00)
вот так и появляется crapware…

---
All Your Base Are Belong to Us

← →
ketmar © (2008-06-07 17:33) [9]

по теме: shared memory ня?

---
Understanding is not required. Only obedience.

← →
Поросенок Винни-Пух © (2008-06-07 17:50) [10]

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

← →
Поросенок Винни-Пух © (2008-06-07 17:54) [11]

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

← →
Eraser © (2008-06-07 18:03) [12]

пайпы (которые не нэймд) и перенапрявление констольного ввода/вывода, либо именованые пайпы. MMF это через чур хардкорный вариант и не дает особого прироста производительности, по сравнению с именованными каналами.

← →
Eraser © (2008-06-07 18:04) [13]

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

← →
Поросенок Винни-Пух © (2008-06-07 18:18) [14]

а в случае с анонимным пайпом что надо сделать, чтобы вспомнгательный процесс использовал его же?
Просто передать значения двух хендлов полученных в основном процессе второму процессу? я верно понял?
или там эти хендлы невалидны будут?

← →
Eraser © (2008-06-08 01:38) [15]

> [14] Поросенок Винни-Пух © (07.06.08 18:18)

> а в случае с анонимным пайпом что надо сделать, чтобы вспомнгательный
> процесс использовал его же?

передать их значения в структуру STARTUPINFO при запуске дочернего процесса с пом., к примеру CreateProcess.
.

← →
Тын-Дын © (2008-06-08 01:56) [16]

Можно также windows-сообщениями воспользоваться.

← →
ага0 (2008-06-08 14:19) [17]

> накладные расходы мне не важны.
> там 16 ядер на четырех зионах

Я фигею, дорогая редакция! шишнадцать ядер и типа все пофиг. Мы блин по 5 км в гору зимой, а вони блин - 16 ядер!

Да те хоть 100 дай - те мало будить! А че ит такова могет сделать сепаратный процесс, чеб не смог основной? Чет сомневаюсь я шибко.

← →
Тын-Дын © (2008-06-08 14:24) [18]

Удалено модератором

← →
ага0 (2008-06-08 14:32) [19]

Удалено модератором

← →
Тын-Дын © (2008-06-08 14:33) [20]

Удалено модератором

← →
ага0 (2008-06-08 14:42) [21]

Удалено модератором

← →
Тын-Дын © (2008-06-08 14:49) [22]

Удалено модератором

← →
ага0 (2008-06-08 14:51) [23]

Удалено модератором

← →
ага0 (2008-06-08 14:53) [24]

Удалено модератором

← →
ага0 (2008-06-08 15:06) [26]

Удалено модератором

Гы-гы.
16 ядер...
Вот поэтому в одной фирме работает 32 ядерный супер комп и за 4 дня решает задачу, которую в соседне фирме, при тех же масштабах, решает 4 ядерный Intel в РЕАЛЬНОМ ВРЕМЕНИ!
А все почему?
Потому что софт для первого сервера писали Авторы... да еще на яве...

← →
ага0 (2008-06-08 15:19) [29]

Удалено модератором

← →
ага0 (2008-06-08 15:51) [30]

Удалено модератором
Примечание: Вот он

← →
ага (2008-06-08 17:16) [31]

Удалено модератором

← →
ага (2008-06-08 17:25) [32]

Удалено модератором

← →
ага (2008-06-08 17:30) [33]

Удалено модератором

как бы сделали вы? Найти похожие ветки