LINUX.ORG.RU

Почему надо проверять malloc на NULL

 , ,


1

3

Вообще выделение памяти проверять.

А вот потому что:

#include <stdio.h>
int main()
{
  unsigned char *a = NULL;
  int b = 0;
  unsigned long n = (unsigned long)&b;
 
  printf("b = %d, n = %lu\n",b,n);
  a[n]=1;
  printf("b = %d\n",b);
  return 0;
}

Запуск

$ gcc nullptr.c -o nullptr
$ ./nullptr 
b = 0, n = 140731726099148
b = 1

Запускалось в 64-битном (x86_64) Linux. Как видно, никаких сегфолтов и прочих ошибок. Конечно, адрес в районе 127 Тб в примере далеко за пределами доступного почти на всех компьютерах, но нет никаких гарантий, что на какой-то системе с каким-то компилятором и настройками среды значение не окажется более доступным. Могут быть и другие архитектуры (32-битные например), если запускать от root'а, то в начало может быть разрешена запись и там иметься память процесса. Или ещё какие-то варианты.

shdown, monk, liksys, Xenius - я думаю вам понравится. Пример сочинился по ходу чтения обсуждения Вышло издание 2,92 книги «Программирование: введение в профессию» А. В. Столярова (комментарий)

★★★★★

Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Кто мешает посмотреть в рантайме на чём процесс запустили и заранее отфутболивать соединения сверх гарантируемо обслуживаемых не доводя до OOM??

Ваши высказывания напоминают поучения от Тони Роббинса: нужно делать как надо, а как не надо делать не нужно.

Может таки перейдете к конкретике и расскажите, а как же надо?

а именно стартовать движок который позволяет по этим данным бегать.

Там не движок стартует. Там данные загружаются и приводятся в должный вид столько времени.

Я не знаю кто это покупает.

Есть вероятность, что вы еще очень и очень многого не знаете.

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

Может таки перейдете к конкретике и расскажите, а как же надо?

Мне мало есть что сказать по сценарию отчуждаемого кода, это не то чем я занимаюсь последние лет 25. Но если вам интересно как народ обрабатывает сотни тысяч и миллионы активных соединений - у нас это скорее обыденность, и вот тут я опытом мог бы поделиться.

а именно стартовать движок который позволяет по этим данным бегать.

Там не движок стартует. Там данные загружаются и приводятся в должный вид столько времени.

Т.е. вы продолжаете это считать нормой. Прочитать терабайт с медленного десктопного диска это макс пара часов (что тоже слишком долго, но уже не 11). Это оценка сверху на то сколько это должно занимать в самом-самом худшем случае. Если эти ребята решили подготавливать image на каждом старте, или обновлять его на каждом старте - это их анальные проблемы. Пользоваться этим невозможно. А если у них эти операции уже независимы - зачем вы манипулируете и включаете это время в рестарт движка?

Я не знаю кто это покупает.

Есть вероятность, что вы еще очень и очень многого не знаете.

Не вероятность, а безусловность - я слишком стар для столь громких заявлений.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от firkax

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

Всё правильно. Но у него будет хотя бы шанс сделать что-то полезное до того как упасть снова, а у вас - шанс подложить фикс который подхватится на след рестарте, или заблокировать «плохой» запрос как-то ещё.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Но если вам интересно как народ обрабатывает сотни тысяч и миллионы активных соединений - у нас это скорее обыденность,

Такое я уже видел.

и вот тут я опытом мог бы поделиться.

Вы бы на простые вопросы, заданный выше, сподобились бы ответить.

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

Вы бы на простые вопросы, заданный выше, сподобились бы ответить.

Ответа который бы вас удовлетворил вы не дождётесь, по причине диаметрально противоположных взглядов. Я утверждаю что отстрелившиеся подушки безопасности - это аварийная ситуация, и лучшее что вы можете сделать это подогнать второй автобус, пересадить пассажиров и продолжить движение (забрав при этом сломанный в мастерскую с целью выявить и устранить первопричину), а вы говорите «у водителя есть в бардачке маникюрные ножницы, пусть он проделает ими дырку во вздувшейся подушке чтобы ему хоть что-то было видно, и как может едет дальше».

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

А NULL от fopen - это что «отсрелилось»?

Я готов ответить на ваши саркастично-офтопичные вопросы, но только после того как вы предложите вменяемую стратегию обработки ошибок аллокации памяти отличную от «retry-few-times-and-abort» которая была бы (а) универсальной, (б) применимой в потоках отличных от главного.

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

Ответа который бы вас удовлетворил вы не дождётесь

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

Я утверждаю что отстрелившиеся подушки безопасности - это аварийная ситуация,

Да, щеки вы надуваете знатно. И аналогии красочные придумываете.

Только вот ваши аналогии ложны, а применяемые приемы очень сильно напоминают демагогию.

eao197 ★★★★★
()

в 2006году реальное выделение памяти происходило не в функции malloc, а при первом обращении к выделеной памяти.
Это знание мне много нервов тогда испортило.
Как сейчас обстоят дела я не знаю.

s-warus ★★★★★
()
Ответ на: комментарий от bugfixer

него будет хотя бы шанс сделать что-то полезное до того как упасть снова,

Или не будет. Никто не гарантирует, что время обработки первого запроса меньше времени до отказа. Подключились N клиентов, поставили запросы в очередь. Пришёл N+1 - все N клиентов обратно на стартовой точке. А если эти клиенты - живые люди? А если эти люди собирают данные от клиентов компании?

ваши саркастично-офтопичные вопросы,

Они очень даже топичные.

стратегию обработки ошибок

Ну наконец-то мы дошли до сути. Чем в рамках общей стратегии обработки ошибок NULL от fopen и malloc принципиально отличаются?

вы предложите вменяемую стратегию обработки ошибок аллокации памяти

Это что, шутка? За 25 + N лет вы ни разу даже ради любопытства не посмотрели в исходники какого-нибудь nginx’а?

Типовая (но не единственно правильная) стратегия - раскручивать назад стек до момента, когда можно будет корректно отазать в обслуживании (например, вернуть ‘503 Service Unavailable’). Если на корректный отказ ресурсов по-прежнему нет - делаем некорректный (connection reset by peer).

Будет ли отказано в обслуживании следующему запросу / клиенту? Не известно. Будет ли отказано в обслуживании существующим клиентам? Не известно, вполне возможно. Но в такой стратегии мы максимизируем шансы корректно обработать запросы от существующих клиентов.

r--r--r--
()
Ответ на: комментарий от eao197

И аналогии красочные придумываете.

Я тоже могу!

Если бы общественный транспорт создавался программистами.

Вышел автобус в рейс, собирает пассажиров. Набрал полный салон, все места заняты. На следующей остановке в него пытается войти ещё один пассажир. Автобус останавливается, выгружает всех пассажиров и возвращается на начало маршрута.

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

На следующей остановке в него пытается войти ещё один пассажир.

Он тупо не войдёт, точнее в моей схеме автобус даже останавливаться не будет если выходить некому. Зато я уверен вы очень рады сложившейся практике продавать больше билетов на авиарейсы, чем физически есть посадочных мест. Это как раз ближе к предлагаемой вами стратегии «будем ждать пока само не отвалится», ага.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)
Ответ на: комментарий от r--r--r--

Чем в рамках общей стратегии обработки ошибок NULL от fopen и malloc принципиально отличаются?

Безусловно отличаются. Как ожидаемостью, так и возможностью последующей recovery.

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

точнее в моей схеме автобус даже останавливаться не будет

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

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

В вашей схеме водила автобуса должен пробежаться по всем остановкам маршрута

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

Вы ведь так и не поняли что от вас хотят. Утверждение следующее: если вы довели до того что память кончилась вы уже что-то делаете не так.

А господин так вообще занял шикарную позицию: «я продаю шины, но я даже знать не хочу какую нагрузку они выдерживают и не буду этим заморачиваться, пусть клиенты делают что хотят; зато я им предоставлю красную лампочку которая загорится когда шина лопнет и они будут знать что с этим делать». Выглядит именно так.

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

Цифры из будущего.

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

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от bugfixer

В моей схеме водитель просто должен знать вместимость своего автобуса

Производители коробочного софта не могут знать в каких условиях этот софт будут эксплуатировать.

Пользователь может открыть Word с большим документом и на это уйдет вся свободная память, а потом, не закрывая Word-а, попробует открыть еще и графический редактор, чтобы подправить картинку перед вставкой в Word. И все. Все «знания о вместимости своего автобуса» превращаются в пустой форумный звиздежь.

А господин так вообще занял шикарную позицию…

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

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

Только вот сюрприз – этот самый пассажир, внезапно, весит 170 кг, вместо среднестатических 80. И?

Или другая аналогия, раз уж вы на меня собираетесь вешать собак под маркой продавца, который не отвечает за то, что продает: я изготавливаю лифты, в которых указываю их максимальную грузоподъемность, например, 320 кг. Но я, как производитель и продавец лифта, не отвечаю за то, что какой-нибудь очень сильный, но очень тупой, дятел захочет спустить на нем с 9-го этажа четыре двухпудовые гири, два грифа от штанги по 10 кг каждый, 10 блинов по 20 кг + свое тренированное тело в 120 кг.

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

Но вот что в моей власти – так это обеспечить кратный запас прочности, чтобы пол кабины не улетел вниз даже при 3-х кратном перегрузе + срабатывание аварийных тормозов. Причем все это мне нужно как-то умудриться сделать так, чтобы себестоимость не улетела в космос.

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

Вместимость автобуса известна

Программа на обработку запроса может потребовать килобайт памяти или мегабайт памяти - требуемый размер будет известен после обработки данных в запросе. Программу запускают на машине с гигабайтом памяти, ОС и остальные программы укладываются в выделенный им фиксированный объём.

Какова "вместимость автобуса"? На каком пассажире автобус проедет мимо остановки?

r--r--r--
()
Ответ на: комментарий от eao197

Пользователь может открыть Word с большим документом и на это уйдет вся свободная память

Как минимум вы можете у системы заранее попросить памяти кратную размеру файла и потом уже внутри апликухи выделять из этого пула. И если оценки были сделаны правильно то эти алокации фейлится не будут.

Только вот сюрприз – этот самый пассажир, внезапно, весит 170 кг, вместо среднестатических 80. И?

Это означает что придётся следить не только за headcount, но и за суммарным весов уже сидящих пассажиров, вот и всё. Да, может вы недоберёте вес который могли бы в теории увезти, но зато тех кого вы взяли доедут без приключений и с комфортом.

Я просто физически не могу сделать должный контроль на входе.

Ещё как можете. Просто не хотите.

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

требуемый размер будет известен после обработки данных в запросе.

После того как запрос распаршен, но задолго до того как вы эту память будете выделять.

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

Как минимум вы можете у системы заранее попросить памяти кратную размеру файла и потом уже внутри апликухи выделять из этого пула.

Насколько кратную? Файл может быть 50Mb в запакованном docx-е, а разворачиваться он может с учетом хитрых стилей и особенностей разметки в десяток гигабайт.

И если оценки были сделаны правильно то эти алокации фейлится не будут.

А если не правильно?

И главный вопрос: зачем все эти приседания и убеждения себя в том, что после NULL из malloc-а жизни нет, если можно рассматривать ошибку аллокации так же, как и все остальные ошибки, препятствующие выполнению работы?

Это означает что придётся следить не только за headcount, но и за суммарным весов уже сидящих пассажиров, вот и всё.

Не все. Ибо как только мы начинаем двигаться из ваших удобных (для вас) красочных аналогий в сторону реального мира, так сразу начинают всплывать дополнительные факторы. Начали просто с количества пассажиров. Затем были вынуждены учесть вес. Следом придется начать учитывать объем, т.к. человек ростом 150 см, но весом под 90 кг, будет занимать места больше, чем двое пассажиров ростом 180 см и весом по 80 кг. Потом в рассмотрение придется взять багаж и т.д., и т.п.

Ещё как можете. Просто не хотите.

Вот вы на вопрос о том, как расчитывать подобные параметры для прокси-сервера не смогли ответить или не захотели?

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

После того как запрос распаршен, но задолго до того как вы эту память будете выделять.

Совершенно не обязательно.

Я не увидел ответа на вопрос:

Какова "вместимость автобуса"?

даже если допущение из п 1. верно.

r--r--r--
()
Последнее исправление: r--r--r-- (всего исправлений: 1)
Ответ на: комментарий от eao197

Файл может быть 50Mb в запакованном docx-е, а разворачиваться он может с учетом хитрых стилей и особенностей разметки в десяток гигабайт.

Если оценка сверху действительно настолько разнится - придётся файл просканировать, да.

после NULL из malloc-а жизни нет, если можно рассматривать ошибку аллокации так же, как и все остальные ошибки, препятствующие выполнению работы?

Эти ошибки на локализируются. Памяти может не хватить модулю A в потоке X, и настоящий виновник вообще в модуле B потоке Y, и модуль A вот ничего разумного по этому поводу предпринять не может. И у вас нет повода думать что последующие алокации магически заработают. Это как продолжать эксплуатировать посыпавшийся винт - вы уже «живете в кредит», надо мгновенно включать damage control и минимизировать потери.

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

Если оценка сверху действительно настолько разнится - придётся файл просканировать, да.

И у вас уже для этого может не хватить памяти.

Эти ошибки на локализируются.

Или вам так кажется, или вы под термином «локалируются» подразумеваете что-то свое.

Памяти может не хватить модулю A в потоке X, и настоящий виновник вообще в модуле B потоке Y, и модуль A вот ничего разумного по этому поводу предпринять не может.

Это не проблема потока X. Приложение откатит свою текущую операцию в потоке X и всех делов. Если в приложении из-за потока Y будут обламываться прочие операции, то пользователь остановит приложение. Например, если он не сможет вставить очередную картинку в свой документ, то он просто закроет Word и все.

И это гораздо лучше, чем мгновенное падение Word-а без каких-либо предупреждений.

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

Я не буду выполнять за вас всю черновую работу.

Пока что это вашим собеседникам за вас приходится хоть что-то конкретное приводить в пример.

Хотя, может быть у вас просто «лапки»?

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

То есть после 100 теоретических постов о том "как надо делать", мы не увидим примера даже на уровне арифметики за начальный классы школы, если не старшие группы детсада?

Я не буду выполнять за вас всю черновую работу.

Вам бы пока за своё балабольство на форуме отчитаться бы надо.

r--r--r--
()
Последнее исправление: r--r--r-- (всего исправлений: 1)
Ответ на: комментарий от eao197

И у вас уже для этого может не хватить памяти.

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

Это не проблема потока X. Приложение откатит свою текущую операцию в потоке X

Ещё как проблема потока X. Это может быть нечто разгребающее очередь сообщений, и вы не можете просто так error out текущее и продолжать со следующими. И что вы будете делать? Error out их всех, останавливать и перезапускать поток, что-то ещё?

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 2)
Ответ на: комментарий от r--r--r--

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

Вам придётся самому собрать данные сколько вам реально памяти на обработку конкретного запроса нужно, и от каких параметров запроса это зависит. Телепаты в отпуске.

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

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

Прекрасно, вы сделаете кусок лишней работы и усложните реализацию. Чтобы что? Допустим, при открытии вы высчитали, что нужно 5GiB, запросили их у ОС, развернули туда содержимое файла. Потом пользователь вставляет в документ картинку и…

Это может быть нечто разгребающее очередь сообщений, и вы не можете просто так error out текущее и продолжать со следующими.

Что значит не можете? Вы берете очередную команду и у вас:

a) либо нет никаких гарантий, что команда может быть исполнена (нехватка RAM, нехватка места на диске, ошибка с правами доступа к диску и пр.) Тогда вы откатываете выполнение команды согласно требований к вашему софту;

b) либо вы имеете эти гарантии, например, за счет того, что ресурсы вы преаллоцировали заранее. Тогда проблем нет.

И что вы будете делать? Error out их всех, останавливать и перезапускать поток, что-то ещё?

Зависит от специфики приложения.

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

Вам придётся самому собрать данные сколько вам реально памяти на обработку конкретного запроса нужно,

И почему я не могу перевесить эту тяжёлую работу на malloc? Вот malloc займётся бухгалтерией в рамках конкретного запроса и вернёт мне NULL, если памяти не достаточно. Я спокойно отреждекчу конкретно этот запрос и

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

r--r--r--
()
Последнее исправление: r--r--r-- (всего исправлений: 1)
Ответ на: комментарий от eao197

Прекрасно, вы сделаете кусок лишней работы и усложните реализацию.

Я упрощаю реализацию там где это критично ценой усложнения пред-проверок.

Что значит не можете? Вы берете очередную команду и у вас

То и значит. Не факт что вы в принципе имеете право процессить эти сообщения out-of-order. Пример: «перевести со счета A на счёт B сумму X» (и тут у нас OOM случился), и следующее за ним «перевести со счета B всё что там есть на C, но если вдруг там меньше Y - заблокировать его нахрен». Как вам такое Илон Маск? А, ну да - у нас же «лапки», чего это я, действительно.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)

:-) если пассажирам в автобусе душно и нехватает воздуха (критически важный, общий ресурс), надо просто выдыхнуть и вернуться в место где воздух ещё был ;-)

MKuznetsov ★★★★★
()
Последнее исправление: MKuznetsov (всего исправлений: 1)
Ответ на: комментарий от bugfixer

Пример: «перевести со счета A на счёт B сумму X» (и тут у нас OOM случился), и следующее за ним «перевести со счета B всё что там есть на C, но если вдруг там меньше Y - заблокировать его нахрен». Как вам такое Илон Маск?

Такие операции должны быть атомарными транзакциями. Классический пример таковых. Если OOM случится в ходе перевода со счёта, перевод не произойдёт. Будет атомарной транзакцией только перевод из А в B или вся операция - это уже зависит от конкретики. Но вообще банковский софт пишется в предсказуемом окружении

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

Я упрощаю реализацию там где это критично ценой усложнения пред-проверок.

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

Пример: «перевести со счета A на счёт B сумму X» (и тут у нас OOM случился), и следующее за ним «перевести со счета B всё что там есть на C, но если вдруг там меньше Y - заблокировать его нахрен».

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

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

В качестве примера вы могли бы привести какие-нибудь команды для управления реальным оборудованием на производстве. Мол, если сперва была команда на включение двигателя, а затем команда для выключения не последовала в течении 15 секунд, то оборудование может выйти из строя (из-за перегрева или еще чего-то). Но вот только подобные системы по управлению пишутся так, чтобы в процессе не было работы с динамической памятью вообще. А в случаях с рисками сбоев с физическим повреждением чего-либо еще и с резервированием. А это как раз те самые случаи, когда все под жестким контролем разработчиков аппаратно-программных комплексов, о которых писалось выше.

Как вам такое Илон Маск?

Уныло. Сравнение меня с недобросовесным продавцом шин было искрометнее. Хотя и так же далеко от реальности.

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

Такие операции должны быть атомарными транзакциями.

Каждая их этих операций - атомарна. Нет ничего плохого если кто-то увидит state после перевода A->B но до перевода B->C. Но вот начинать процесить перевод B->C никак нельзя если пред операция по каким-то причинам зафейлилась. И господин @eao197 прекрасно понимает насколько сильно нужно будет корёжить API чтобы дать возможность клиенту который эти транзакции в очередь положил принять какие-то осмысленные решения.

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

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

Пример шикарный. У вас есть модуль который принимает запросы на транзакции (с подтверждениями, локальным persistence’ом если нужно и всеми bells-and-whistles которые вы только можете придумать). Он принял N последовательных(!!) запросов, подтвердил что он их принял (клиент знает что ресабмитить не нужно и ждёт финального подтверждения об исполнении), и тут в модуле в треде который процессит очередь этих запросов прилетает OOM. Что конкретно должно происходить и как именно этот модуль реагировать на этот OOM? Ваша часть - менеджер этой очереди которому дали hooks за которые дёргать чтобы запроцессить конкретное сообщение, и callback за который нужно дёрнуть чтобы послать ответ клиенту. OOM случился в момент формирования downstream запроса в треде порождённом и владеющимся менеджером. Что этот менеджер в принципе может сделать кроме как упасть, и если может - как именно должен выглядеть соответствующий API?

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

Пример шикарный.

Пример бездарнейший.

тут в модуле в треде который процессит очередь этих запросов прилетает OOM.

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

Этот пример примерно никак ничего не показывает и не доказывает, и уж тем более не доказывает, что на любой NULL от malloc’а надо abort’иться.

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

Этот пример примерно никак ничего не показывает и не доказывает, и уж тем более не доказывает, что на любой NULL от malloc’а надо abort’иться.

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

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

Вы даже не в состоянии распарсить что там написано и понять суть проблемы.

Я пока что распасрил, что за 100 постов ни одного аргумента в пользу падения всегда везде и сразу не было приведено, а практики десятков, если не сотен опен-сурс (и несчётного множества коммерческих) проектов для вас попросту не существует.

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

за 100 постов ни одного аргумента в пользу падения всегда везде и сразу не было приведено,

«Смотрю в книгу, вижу фигу». Что тут ещё скажешь. Мальчик, оставь дяденек в покое.

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

И господин @eao197 прекрасно понимает

Вы бы это… Не делали предположений о том, что думают, знают или понимают ваши собеседники. А то очень похоже на постановку диагнозов через Интернет. С таким же уровнем достоверности.

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

Вы бы это… Не делали предположений о том, что думают, знают или понимают ваши собеседники

Хорошо, если вам больше нравится чтобы я считал что вы не понимаете о чём речь идет - давайте на этом разбежимся, на вопрос выше отвечать тогда тоже вовсе необязательно.

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

Пример шикарный.

Есть ли кто-то в зравом уме, кто разделяет эту точку зрения?

Он принял N последовательных(!!) запросов, подтвердил что он их принял (клиент знает что ресабмитить не нужно и ждёт финального подтверждения об исполнении)

Не понял какое значение здесь имеет слово «последовательных».

и тут в модуле в треде который процессит очередь этих запросов прилетает OOM. Что конкретно должно происходить и как именно этот модуль реагировать на этот OOM?

Раз вы начали фантазировать, то тут следовало бы рассказать, а в чем, собственно, «процессинг» состоит.

Ваша часть - менеджер этой очереди которому дали hooks за которые дёргать чтобы запроцессить конкретное сообщение, и callback за который нужно дёрнуть чтобы послать ответ клиенту.

Почему это моя часть и почему она выглядит именно так? Вы выдумываете что-то странное, а потом требуете, чтобы я как-то выкручивался из того, что вы навыдумывали.

OOM случился в момент формирования downstream запроса в треде порождённом и владеющимся менеджером

Здесь не понял кто на ком стоял.

Что этот менеджер в принципе может сделать кроме как упасть

Опять же хз что за «менеджер» и зачем ему падать.

Если говорить об абстрактных конях в вакууме, то ключевой момент в том, что вы сами выделили «подтверждение приема сообщения» и «подтверждение выполнения». Это значит, что подтверждение приема вовсе не означает подтверждение выполнения. И это так же значит, что клиент должен быть готов к тому, что после получения подтверждения приема он может не получить подтверждения выполнения.

Исполнитель сообщений беря в работу очередное сообщение должен подготовить все ресурсы, необходимые ему для обработки этого конкретного сообщения. Например, сразу аллоцировать ответное сообщение (но не отправлять его). И только после того, как все ресурсы для обработки текущего сообщения на руках, сделать обработку. А потом отправить ответное сообщение (которое уже готово и просто ждет).

Соответственно, если в процессе подготовки ресурсов что-то пойдет не так, то вовсе не нужно падать. Достаточно откатить то, что было выделено. Клиент не получит сообщения о выполнении, что есть вполне ожидаемая ситуация.

PS. Ну и здесь тов.anonymous_incognito выше верно заметил, что подобные системы делают с расчетом на конкретные параметры. Например, на 1000 транзакций в секунду с «окном» в 30 секунд, в течении которого необработанные транзакции могут скапливаться (например, из-за тормозов или отсутствия связи с внешними сервисами, без которых обработка транзакций не возможна). Под такой объем заранее аллоцируются ресуры, а все запросы, идущие сверх оговоренных и зафиксированных параметров просто отфутболиваются. Подобный подход принципиально отличается от использования «коробочных» продуктов в произвольном окружении произвольного пользователя.

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

на вопрос выше отвечать тогда тоже вовсе необязательно.

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

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

то ключевой момент в том, что вы сами выделили «подтверждение приема сообщения» и «подтверждение выполнения». Это значит, что подтверждение приема вовсе не означает подтверждение выполнения. И это так же значит, что клиент должен быть готов к тому, что после получения подтверждения приема он может не получить подтверждения выполнения.

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

Соответственно, если в процессе подготовки ресурсов что-то пойдет не так, то вовсе не нужно падать.

Просто расскажите в 2х словах что по вашему мнению при внутренних ошибках такого модуля должно происходить? Подчеркиваю: всё асинхронно, очередь дальше процессить проигнорировав хотя бы одно сообщение - нельзя. Вы же любите быть прозрачными в плане ошибок и не любите падать, вот я и хочу увидеть как это можно красиво реализовать.

bugfixer ★★★★★
()
Последнее исправление: bugfixer (всего исправлений: 1)
Ответ на: комментарий от monk

И военный корабль на несколько часов потерял ход.

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

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

Просто расскажите в 2х словах что по вашему мнению при внутренних ошибках такого модуля должно происходить?

Какого модуля и каких «внутренних ошибках»?

Как по мне, так внутренняя ошибка модуля – это когда модуль делает деление на 0, обращается по невалидному указателю или пытается писать в файл не проверяя результат открытия.

А когда модуль пытается получить память и встречает NULL из malloc-а, то это нештатная ситуация. Которая может рассматриваться так же, как невозможность открытия файла или потеря соединения с СУБД.

Это не ошибка модуля. Ошибкой модуля будет игнорирование NULL-а.

Подчеркиваю: всё асинхронно

Не вижу при чем здесь асинхронность.

очередь дальше процессить проигнорировав хотя бы одно сообщение - нельзя.

Оно не игнорируется. Сообщение взяли, не смогли собрать ресурсы для его обработки, следовательно обработка сообщения завершилась неудачно. Может быть с записью сего факта куда-то, может нет.

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

Если у вас каждое следующее сообщение в очереди зависит от результата обработки предыдущего, то:

  • возможно, у вас ошибка в дизайне. И вам нужно передавать не N отдельных сообщений, а всего одно, с описанием N операций внутри. И рассматривать такое большое сообщение как одну транзакцию;

  • если же это не ошибка в дизайне, а особенность предметной области, то вам нужно вводить какой-то механизм маркеров для обозначения групп связанных между собой сообщений. Типа сперва идет N сообщений, увязанных в одну логическую группу, затем специальный маркер окончания группы, затем M сообщений, увязанных в другую логичекую группу, затем специальный маркер и т.д. Соответственно, когда i-е сообщение текущей группы обработать не удается, то обработчик очереди переходит в состояние, когда он дает «отлуп» всем следующим сообщениям из этой группы до тех пор, пока не прочитает следующий маркер. При этом вам еще нужно как-то решить проблему с откатом обработки сообщений текущей группы, которые были до i-го сообщения (чтобы обеспечить транзакционность обработки всей группы). Причем вам этот откат нужно делать и при abort-е после malloc-а.

вот я и хочу увидеть как это можно красиво реализовать

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

eao197 ★★★★★
()
  • Markdown
Пустая строка (два раза Enter) начинает новый абзац. Знак '>' в начале абзаца выделяет абзац курсивом цитирования.
Внимание: прочитайте описание разметки Markdown.
Используйте Ctrl-Enter для размещения комментария