На первый взгляд идея кажется бредом, но все же, вдруг есть какой-то старый индейский способ? Суть такова: я хочу, чтобы каждый запрос сервер отрабатывает в отдельном процессе, как это например умеет делать апач. Вот какие сценарии приходят в голову: 1. Сервер принимает входящее соединение, стартует второй процесс и каким-то магическим образом передает второму процессу сокет o_O 2. Сервер принимает входящее соединение, стартует второй процесс, второй процесс коннектится на сервер по локалхосту, отрабатывает запрос, передает респонс, а сервер просто форвардит этот респонс клиенту. 3. Сервер принимает входящее соединение, стартует второй процесс, и больше не принимает соединение, а занимается отработкой запроса и отсылкой ответа, а ожиданием следующего клиента уже занимается только что запущенный процесс. Какие варианты есть еще? Какие варианты в принципе используются в жизни?
_DEN_ Гугл за 2 минуты дал. Х.з как работает, никогда не юзал. WSADuplicateSocket http://msdn.microsoft.com/en-us/library/ms741565(VS.85).aspx Это для винды. Для никсов fork должен без проблем решить вопрос. Хотя тоже х.з.
Я может быть сейчас спорю чушь, но насколько я знаю, в винде сокет привязывается к IOCP только один раз, и потом его сменить нельзя, а на втором процессе есть свой IOCP, с которым надо работать...
Я не знаю, о чем ты сейчас говоришь, но пользоваться одним сокетом в двух разных процессах можно. Апи для этого тебе назвали
Надо эксперементировать. Я сейчас не совсем понимаю, прокатит ли дублирование сокета при его передаче с одного boost::asio::io_service на другой.
_DEN_, какая ось? Если вин, то зачем создавать другой процесс, есть треды. Если никс, пишите в память процесса и int 80h вам в руки.
litrovith Вин. Процесс нужен потому что в нем будет жить бажная либа, которая виснет, крашится и мемликает. Чтобы проблемы либы не оборачивались проблемами для ее клиентов.
_DEN_ Распространяя *nix'овый опыт могу сказать, что напрашиваются два варианта. Либо: Только я бы вывернул всё несколько иначе. Второй процесс запустил бы как и первый -- демоном. И первый работал бы как прокси. В венде, говорят, процессы долго стартуют, и запускать на каждое соединение по процессу накладненько будет. По необходимости, можно запустить N "вторых" процессов, и разбрасывать входящие соединения по ним ровным слоем. Либо SHM. Я уверен что в венде должно быть что-то этого рода. Завести кусок памяти доступный в rw обоим процессам. Первый туда пишет read'ом, второй оттуда читает. Только при таком подходе, очень сложно присобачить стандартные user-space библиотеки IO: они не умеют работать с SHM, и заполнять их буфера из одного процесса, а освобождать из другого -- это нетривиальная задача. Хотя, я уверен, C++ программист, привыкший ковыряться в исходниках STL и Boost с этим справится вполпинка. С stdio это сложно провернуть, поскольку там не предусмотрено создание типов производных от FILE. А с чисто C++ библиотекой, всё должно быть просто, как я понимаю.
погуглил эти страшные слова и вот какую ссылку нашел: http://www.rsdn.ru/forum/winapi/1294114.flat.aspx возможно, она поможет ТС
r90 В бусте есть Boost.Interprocess - там и шаред мемори, и прочие плюшки. С тредпулом с процессами вместо тредов идея хорошая, но у меня скорость старта процесса не критична - это клиент-серверная система для малого числа юзеров, работающая в локалке - на нее не будут ломиться по стопитсот человек одновременно То есть у меня можно сделать выбор в пользу простоты, т.к. оверхед не страшен. А как работает апач? Просто дупает хендл и форкается?
_DEN_ На венде? Не знаю. В апаче есть несколько т.н. Multi-Processing Modules, в частности есть модуль под названием winnt. Как он работает я не вникал. В *nix'ах, как я понимаю, слушающий сокет слушают все процессы и все потоки каждого процесса. Как-то там синхронизируются, чтобы одновременно не вызывать select, и кто первый крикнет accept, тот и будет разгребать соединение. Или ты про то, как он передаёт сокет потенциально бажной "библиотеке" типа скрипта на php, написанного быдлокодером? А этим занимается не апач, а модули, типа mod_php, mod_cgi, mod_proxy и т.п. И в разных ситуациях используются разные модули.
_DEN_, зачем "дупать хендл" если есть accept, возвращаемый хендл которого передаётся в создаваемый поток. Индеец, епта! add seh заюзать не судьба?
факт что поможет? ( вопрос риторический ) , но ответ НЕТ. К примеру, либа просто портит свои же данные и виснет, даже эксепшена нету.
spa, Риторический ответ: факт в том, что лучше наступать на СВОИ грабли(к держаку можно подушку прикрутить и не падать!).
_DEN_, научитесь читать. И ,не прибегая к индейской магии, у вас всё получится, или подкиньте мне кофейной гущи.
