Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Ну и где? И лежит ли?
Там, где его можно увидеть изнутри ребеночка, а следовательно и утащить...
Если начинать пинговать сразу после handshake-a...
Стасм ну блин же, ты что, меня действительно в упор не понимаешь?
Что без доступа к ключу из детеныша будет апачу жопа?
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Ну и где? И лежит ли?
Там, где его можно увидеть изнутри ребеночка, а следовательно и утащить...
Если начинать пинговать сразу после handshake-a...
Стасм ну блин же, ты что, меня действительно в упор не понимаешь?
Что без доступа к ключу из детеныша будет апачу жопа?
Блин ну же... После рукопожатия ключ уже не нужен. ключ лежит в нижних адресах (потому как память для него замаллокилась сразу), а память экспозится от поинтера вверх.
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Ну и где? И лежит ли?
Там, где его можно увидеть изнутри ребеночка, а следовательно и утащить...
Если начинать пинговать сразу после handshake-a...
Стасм ну блин же, ты что, меня действительно в упор не понимаешь?
Что без доступа к ключу из детеныша будет апачу жопа?
Блин ну же... После рукопожатия ключ уже не нужен. ключ лежит в нижних адресах (потому как память для него замаллокилась сразу), а память экспозится от поинтера вверх.
Я же тебе объяснил, рукопожатие может длиться несколько сотен миллисекунд, до 1-2с доходит, потому что надо пакеты туда-сюда гонять несколько раз, пока они договорятся.
Если это делать в главном процессе, то это означает, что куча новых реквестов будет висеть в очереди и ждать... throughput упадет нафиг...
А детеныш форкается от практически ничего не делающего папы, у которого куча пустая...
Т.е. у каждого нового детеныша ключ лежит достаточно близко...
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Осталось только согласиться, что у папы перед ключом могут быть дырки в куче...
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Конечно доступен. Только он не копируется, а лежит там гдеего папа положил. Я не могу придумать ситуацию, когда ключ окажется "ниже" хеартбита, а ты?
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Конечно доступен. Только он не копируется, а лежит там гдеего папа положил. Я не могу придумать ситуацию, когда ключ окажется "ниже" хеартбита, а ты?
Я там выше потом добавил, все может сильно зависеть от того, какие модули загружаются, в каком порядке и что они делают...
Но вероятность того, что перед ключом возникнет дырка, которая уйдет в форк, достаточно большая...
И чтоб два раза не вставать ты бы внимательно Федю своего прочитал. Он там явно говорит, что ключ грузится один раз и в дампах оказаться никак не может.
AlexeyUat писал(а):И чтоб два раза не вставать ты бы внимательно Федю своего прочитал. Он там явно говорит, что ключ грузится один раз и в дампах оказаться никак не может.
ну не важно, что именно, праймы же он достал... а значит была перед ними дырочка, в которую его heartbeat положили...
И в догонку, в Апаче такая дырка может прожить в папе намного дольше чем NGINX-e.
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Осталось только согласиться, что у папы перед ключом могут быть дырки в куче...
Станислав сомневался где рукопожатие происходит, но если в чайлде, то разумеется ключ должен быть доступен.
Чтобы в куче возникли дырки, надо какой-то модуль выгрузить, что врядли.
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Осталось только согласиться, что у папы перед ключом могут быть дырки в куче...
Станислав сомневался где рукопожатие происходит, но если в чайлде, то разумеется ключ должен быть доступен.
Чтобы в куче возникли дырки, надо какой-то модуль выгрузить, что врядли.
а что, какой-нибудь модуль во время загрузки не может сделать malloc/free? До загрузки private key, но такого размера, что private key туда не влезет...
Marmot писал(а):
Вопрос практику: где лежит private key в апачевском child process после форка?
Там же где и лежал в родительском естественно. Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может.
Ну т.е. вы согласны, что он из ребенка доступен и им используется, а то вот Станислав в этом сомневался...
Осталось только согласиться, что у папы перед ключом могут быть дырки в куче...
Станислав сомневался где рукопожатие происходит, но если в чайлде, то разумеется ключ должен быть доступен.
Чтобы в куче возникли дырки, надо какой-то модуль выгрузить, что врядли.
а что, какой-нибудь модуль во время загрузки не может сделать malloc/free? До загрузки private key, но такого размера, что private key туда не влезет...
МОдуль грузится и аллокирует память для постоянных данных - зачем ему освобождать? Это ж не Джава и не С# - породил объект и тут же убил
Stanislav писал(а):МОдуль грузится и аллокирует память для постоянных данных - зачем ему освобождать? Это ж не Джава и не С# - породил объект и тут же убил
Ну примитивно, например, прочитал конфиг файл в буфер, распарсил, буфер освободил...
Stanislav писал(а):МОдуль грузится и аллокирует память для постоянных данных - зачем ему освобождать? Это ж не Джава и не С# - породил объект и тут же убил
Ну примитивно, например, прочитал конфиг файл в буфер, распарсил, буфер освободил...
Stanislav писал(а):МОдуль грузится и аллокирует память для постоянных данных - зачем ему освобождать? Это ж не Джава и не С# - породил объект и тут же убил
Ну примитивно, например, прочитал конфиг файл в буфер, распарсил, буфер освободил...
хм... у модуля конфиг? в апаче? в чайлде?
зачем в чайлде, в папе, еще пример, сам mod_ssl читает сертификаты, использует буферы, потом их освобождает, остается дырка у папы, папа форкает детеныша, у детныша будет та же дырка... согласен?
Его положение в памяти может измениться только если форкнутый процесс изменит ключ чего естественно в твоем случае произойти не может. 