iv_an_rumaytonпропущено...

Вот с этого момента - непонятно. Что логично? Сначала catch-блоки? Почему?

Где хотя-бы рациональное объяснение? Goto "назад" это логично?С овсем логично было бы написать все обрабочики особых случаев не сверху и не снизу а сбоку, как в SDL/GR. Goto "назад" выглядит плохо, но он выглядит _лучше_, чем goto-невидимка, о существовании которого можно узнать только дочитав до catch-ей в конце. Кроме того, никто не мешает вам написать define continue/exit handler всего на одну строчку выше того места, где вы ожидаете получить особое состояние, так что goto "далеко назад" --- не самая частая вещь.
maytonИли логично следование традициям pascal-подобным языкам где есть блок "declare" ... ?П осинтаксису языка, совершенно необязательно писать все define...handler в виде единого блока. Просто "оно само так получается". Наоборот, сишный try-catch вносит ненужное разнообразие. Вот есть у вас функция, которая получает блок данных предположительно соответствующих некоему формату, и пихает их в новый файл. Есть у неё два регулярно встречающихся особых случая. Один --- несоответствие формату, что проверяется вызовом валидатора перед открытием файла, и второй --- errno в файловой операции. Почему ветки кода для них должны быть записаны в разных концах функции? :)

Вообще-то совсем логично иметь среду, которая от тебя вообще не требует написания каких-то там обработчиков.
От слова совсем.

Никаких, нигде.

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

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

И это единственный тру способ (помереть процессу), если, конечно, ты не пишешь GUI

Anatoly MoskovskydbpatchИ это единственный тру способ (помереть процессу), если, конечно, ты не пишешь GUI
А если в демоне происходит, ну допустим ошибка в одном подкюченных сеансов - это тоже помереть? Вместе с тысячами других сеансов, где не было ошибки?

в том-то и дело, что это ок :)

полезно иногда смотреть по сторонам, как у других людей сделано. к примеру в Erlang и PHP (внезапно) подобное поведение является by-design.

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

т.е. там можно конечно обрабатывать исключения, но в базовой философии - это как раз не нужно делать, live-to-die, умри молодым :)

возвращаясь к "нашим баранам" - в Erlang все окружение полностью контролируется средой, dangling pointer не возможны в принципе, 100500 процессов это не тру процессы с точки зрения O/S, а самые обычные корутины и там это реально работает,
ибо среда выполнения это все контролирует.

в типовом C/С++ приложении ничего такого нет, и да, тебе в виде начального задания придется написать монитор процессов (запускатель, отстреливатель повисших, перезапускатель оных - для бедных - systemd).

и ввести правило - один клиент, один процесс.

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

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

но в целом - создать процесс в наше время неприлично дешево, так что все нормуль, пилим нетленку дальше :)

iv_an_rudbpatchПотому что программист - он оптимист, он думает только о том, как его решение успешно пройдет шаги, а думать на каждом шаге "ой, а что тут может случиться" - слишком утомительно для нашей бренной и короткой жизни.Пока в отрасли так много оптимистов, я могу не переживать насчёт будущей зарплаты --- квалифицированные пессимисты всегда будут востребованы :)

А исцеляется оптимизм одним простым способом, про который я уже писал. Оптимист АСУчивает газораспределительный пункт, бригада оптимиста укрывается в складках местности, оптимист заходит в будку этого ГРП и с местного пульта всё включает. Ну, если доживёт до конца процесса, то всё включает, а если нет --- уж сколько успеет. Но это только начало лечения. Через два месяца он заезжает к котельной, питающейся через тот ГРП, и говорит машинистам, что если что-то в последнее время шло не так, то это именно из-за него оперативный персонал остался без премии за экономию топлива.

ой, страшно аж жуть. осталось душещипательную историю про танк, кувалду и медведей дописать, чтоб все прочувствовались.

но а по теме что-то будет?

dbpatchAnatoly Moskovskyпропущено...

А если в демоне происходит, ну допустим ошибка в одном подкюченных сеансов - это тоже помереть? Вместе с тысячами других сеансов, где не было ошибки?

в том-то и дело, что это ок :)

полезно иногда смотреть по сторонам, как у других людей сделано. к примеру в Erlang и PHP (внезапно)

для вяще сумлящихся - в типовой связке LAMP именно так и сделано - один клиент на один процесс.

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

а проблему 100500 клиентов обычно решает рядом стоящий nginx - использовать апач для коммуникации с какой edge мобилкой за 2000 км слишком дорого - апачу проще отдать весь ответ nginx-у, а самому заняться другим клиентом-запросом, чем держать выделенный процесс десятки секунд просто для того, чтоб отдать десяток килобайт

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

P.S. Не спорю, что шкурку с кошки можно обдирать разными способами, но это же не повод идти в крестовый поход за единственно правильную веру.

ок, и что там изменилось?

ps -ef|grep httpd ты уже запустил, или apache рассматриваешь исключительно на своей Windows машине?

dbpatchок, и что там изменилось?

ок, согласен, иногда полезно вспомнить давно закрытый вопрос.
да, действительно, по дефолту в apache 2.4 стоит выбор event (внезапно), включать prefork нужно вручную.

работать с преднастроенными образами - оно да, расслабляет.

тем не менее, рассматривать event и worker я бы не стал, эти костыли нужны только если у тебя нет nginx/haproxy,
а не иметь их могут себе позволить лишь совсем стартапы, с мини трафиком в сотню запросов за сутки.

а вот иметь их для app server, а не статической раздавалки файлов - это уже как минимум странно. впрочем, клиент спишет на провайдера, да?

но при наличии nginx использовать apache как CDN.... короче

Anatoly Moskovskydbpatchв том-то и дело, что это ок :)
Проблема в том, что это ОК только в 0.01% всех приложений.
И человек умеющий только в таком стиле писать программы будет очень долго искать работу.

не все пишут GUI на С++, как ты :) в остальном - извини, но даже LAMP - это никак не 0.01% приложений, так что мимо, все как раз ок.

плюс на описанном мной ок принципе, внезапно, работает Oracle, и, ЕМНИП, даже постгрес https://www.postgresql.org/docs/9.1/static/tutorial-arch.html

и это тоже как-то вовсе не 0.01%. так что у тебя или проблемы с пониманием сказанного (это ок, если ты совсем начинающий) или с кругозором (это уже не ок)


опять же - падать положено именно при отлове необработанного исключения.

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

iv_an_rudbpatch...костыли нужны только если у тебя нет nginx/haproxy,
а не иметь их могут себе позволить лишь совсем стартапы, с мини трафиком в сотню запросов за сутки. http://dbpedia.org/sparql безо всяких проксей обмолачивает по десятку миллионов запросов в сутки ;)

и что с того? даже IIS такое может.

если у тебя приложение стабильно и отлажено годами, то даже схема с multi-thread unmanaged web c++ single-process server будет работать, и даже стабильно, и даже недеями.

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

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

schidbpatchплюс на описанном мной ок принципе, внезапно, работает Oracle

Внезапно Oracle работает по-разному, в зависимости от настроек.

да нет там никаких таких настроек. опцию многотредовости экспериментально запилили лишь в 12-й версии, именно как опцию, в ближайшие несколько лет это out-of-scope
по дефолту там тот-же самый single-thread single-process-per-client-session

вариант "сервера" под Windows я рассматривать не буду - у кого это работает, тот молодец, честь, хвала и совесть нашей эпохи, значок ГТО и грамота как передовику производства.


сам же я подожду когда они доделают туда работоспособный bash и остальное окружение (подвижки в WSL есть, Clang/C2 в WS это пять, но пока это только эксперименты для гиков)

Anatoly Moskovskydbpatchне все пишут GUI на С++, как ты :)
Вы ошиблись. Это другой известный сишник перешел на С++ чтобы писать гуй. Он тут модером подрабатывает ))
тебе же хуже, значит ты просто не умеешь писать серверы на C++

Anatoly Moskovskydbpatchно даже LAMP - это никак не 0.01% приложений, так что мимо
Это платформа, на которой приложения пишутся на скриптах, где никто не падает, а нормально показывает ошибки прямо в скрипте (поделки школьников не в счет). Так что да - мимо )))
Нет не мимо, в LAMP worker-ы даже если не упадут внезапно, то монитором рано или поздно будут перезапущены.
Ибо есть падения, а есть еще и утечки (и памяти, и хендлов). Которые не только школьники оставляют.
Так что да, ты опять мимо, изучи уже основы.

Anatoly Moskovskydbpatchплюс на описанном мной ок принципе, внезапно, работает Oracle, и, ЕМНИП, даже постгрес https://www.postgresql.org/docs/9.1/static/tutorial-arch.html
Они создают процесс на клиент, но не падают на чихи, т.к. не достаточно завершить процесс, а надо откатить транзациию. А это не одна строчка кода. Так что это нифига не ваш принцип.

у тебя я смотрю фундаментальная дырища в знаниях. если оракловской процесс упадет по ORA-600, кто за него будет откатывать транзакцию?

а если подумать?

Anatoly MoskovskyА ваш принцип простой: программа должна работать в тепличных условиях, а если условия минимально не те, то это не ваши проблемы.
Такой принцип очень удобен для программистов создающих программы которыми никто не пользуется )))

Ты опять ничего не понял. Ну что за тормоза, соберись уже!

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

Он как раз и ожидает вечно тепличных условий - у него других не бывает. Даже QA или тестер для прикладника уже разновидность
катастрофы - чуть юзер не ту кнопку нажал, оопс, корка полилась. И они там дружно лишь купируют проблему
ненадежного софта, делая подпорки и костыли.

Но перед любой новой потенциально нетестирумой проблемой этот ваш try/catch типа код так и остается беззащитен.

Anatoly Moskovskydbpatchв типовом C/С++ приложении ничего такого нет, и да, тебе в виде начального задания придется написать монитор процессов (запускатель, отстреливатель повисших, перезапускатель оных - для бедных - systemd).
Кажется ваша компания обанкротится раньше, чем вы напишете первую полезную строчку кода.
Вы как уже, дописали все эти мониторы или вот-вот?
Да отлично все работает уже четвертый год, спасибо за заботу.

Anatoly Moskovskydbpatchи ввести правило - один клиент, один процесс.
Какой лимит на количество процессов в линуксе, в курсе? Какой оверхед процесса по сравнению с вызовом функции, в курсе?
Ой господи, детский сад, штаны на лямках.

Вна уже перестали проходить теорию массового обслуживания? Про очереди совсем не знаем?
Или ты всерьез считаешь, что количество кассиров на кассах должно быть равно числу покупателей в торговом зале?

Угар.

Anatoly Moskovskydbpatchа проблему 100500 клиентов обычно решает рядом стоящий nginx
А nginx-у извините тоже падать если что? Или его пишем по своим правилам? А монитор процессов, кстати, тоже падает на каждый чих?)))
С какого перепугу? nginx априори стабилен, там нет прикладного кода, все переходы и диаграммы состояний детерменированы,
там просто нечему падать, ибо круг его задач (и пространство падений) жестко ограничен.

nginx/haproxу это просто дистпетчеры запросов - они держат всю keep-alive поднаготную с клиентами, строят keep-alive (уже свои, не имеющие ничего общего с клиентскими) с apache серверами и занимаются высокоуровневой маршрутизацией запросов.

Т.е. 100500 висящих клиентских сессий на nginx спокойно могут обслуживаться всего десятком процессов на apache (читаем про реализацию comet серверов на nginx в т.ч., хотя это отдельно).