> man ACCEPT(2) При чём здесь man accept? Мне казалось очевидно, что речь идёт о том самом server->accept(), но может быть с несколько иным прототипом, чтобы каким-нибудь образом позволить использовать его в качестве условия для while.
> Один вызов accept() - обработать одно соединение. Думаю догадаетесь как обработать N
> соединений.
При написании кода, вопрос не как обработать N соединений, а как написать код так, чтобы понять его через полгода. Чтобы этот код был бы понятен даже тому, кто думает как надо обработать N соединений. Один и тот же алгоритм можно написать тысячью способов, и когда ты будешь читать один из этих способов в коде, тебе надо будет понять, что именно это за способ. Не просто придумать как обработать N соединений, а понять что там напридумывал автор кода.
Вопрос в том, как написать код, в котором можно искать баги. Как написать код, о котором можно рассуждать и, в процессе поиска багов, или поиска пути как внести желаемые изменения, доказывать в голове, что "в этой функции не может возникать сегфолт, потому что...", или "этот кусок памяти не может утекать, потому что...". Те возможности, которые язык предоставляет для такого -- это одно из самых важных свойств языка. Всё остальное преходяще.
>>Но вопрос не в том как реализовать, а в мотивации для отказа от той реализации, которая есть.
> Вопрос именно в этом, то есть как обработать N соединений, если accept() обрабатывает одно за вызов.
Как угодно, лишь бы результат отражал бы в коде всё, что нужно про него знать читая этот код. control flow -- это важная вещь, которая должна быть отражена. Структурное программирование не зря придумывали, и никаких longjmp'ов там не было. Некоторые даже с goto боролись до того, что этот самый goto начали выкидывать из языков, местами предлагая взамен совершенно уродские языки. Некоторые даже return выкидывали. С return'ом это пожалуй перебор, но вот longjmp не нужен точно. Если ты конечно не пытаешься на нём реализовать библиотечку coroutine'ов, или ещё какую юзерспейс многозадачность, и используешь longjmp для переключения контекстов.
>> Такой подход скрывает логику работы, понимание которой существенно для понимания того, как работает этот цикл и что он делает. Это скрытый control flow, относящийся к обработке штатных ситуаций.
> рассмешили вы меня тут)))) а как же парадигма ООП, прячь все поглубже?
> ))) вот вам и результат Ц++, а не лапшекод из условных
> операторов на Си, примеры на Си из пхп выше.
Ну да, возможно это ситуация "заставь дурака богу молиться". Если довести идею инкапсуляции до абсурда, то мы получим чёрную дыру, которая ничего не выпускает наружу и сжирает всё, что оказывается достаточно близко. Идеальный инкапсулятор. Совершенно бесполезный. Но в том-то и дело, что инкапсуляцию, как и любой другой инструмент, следует использовать с умом. Вне зависимости от того, пишем ли мы в ООП парадигме или в какой-то другой.
>>В результате мы получаем, что сервер написанный с использованием fcgi будет выполнять штатное завершение через нелокальный выход при помощи throw. Это будет работать, но так делать не надо.
> с чего вы взяли, что выход из "вечного цикла" возможен только лишь
> при нештатных ситуациях? Вы код автора открывали? Выше указал даже номера
> строк.
С чего вы взяли, что мы взяли, что выход из вечного цикла возможен лишь при нештатных ситуациях? Мы говорили о том, что штатная ситуация обрабатывается как нештатная. Штатная ситуация обрабатывается нештатным нелокальным goto.
>>но для каждой функции описывать структуру с возвращаемым типом -- это всё же бред
> О да, это прям как - всё есть класс )
Нет, не всё есть класс. Это совершенно перпендикулярные понятия. Есть значения, которые позволяет передавать информацию. Скажем значение вида
struct MaybeToken {
bool ok;
union {
Token tok;
Error err;
}
};
позволяет вернуть из функции токен, если он найден, или ошибку, если он не найден. Ошибка при этом может быть содержательной и обрабатывая её мы можем вывести приятное сообщение об ошибке. Или мы можем выполнить какой-нибудь recovery для каких-то из возможных ошибок. Или мы можем преобразовать ошибку к другому типу ошибки, который будет более осмысленным выше, и вернуть её. В C принято выкручиваться всякими разными способами, типа кодировать ошибку отрицательными значениями целочисленной переменной, для которой осмысленны только положительные значения. Или возвращать NULL вместо указателя (таким образом сообщая о факте ошибки, но если причин ошибки может быть несколько и вызывающий код хочет их различать, то это не работает). Или возвращая значение из функции складывая его по переданному указателю, а возвращаемым значением функции выдавать код ошибки. Но это же всё костыли, и естественно возникает желание придумать общий способ для всех. Страуструп придумал исключения, но причёсанняй longjmp как способ обработки ошибок -- это гумно, и опыт C++ показал, что гумно это не только по каким-то замудрёным теоретическим причинам, типа потому что нарушение принципов структурного программирования, но и по вполне практическим.
> Ну и я не понимаю, зачем нужны вообще всякие ЯП, когда есть
> КОП процессора :)
КОП какого процессора?
