Перейти к содержимому

fork() в CGI

Началось всё с того, что aspell периодически падает при предложении вариантов правильного спеллинга если, например, английским словарём проверяются и английские и русские слова. Конечно некузяво юзеру периодически выдеть сообщение о внутренней ошибке сервера, поэтому эту проверку завернул в отдельный процесс, создаваемый при помощи fork(), -- отработал -- хорошо; упал  -- не страшно, родительский процесс пойдёт дальше, пользователь увидит результат, хотя и без проверки спеллинга.

Но не тут-то было, оказывается  Apache и lighttpd  стали выводить HTTP-заголовки, выдаваемые CGI-мождулем дважды, один раз где положено, среди заголовков ответа, второй раз -- непосредственно вначале тела ответа. Причём, если у Apache включен KeepAlive, то всё отрабатывает правильно (проблемы нет).

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

fork() в CGI: 3 комментария

  1. ooptimum

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

    ЗЫ. lighttpd, а не lighthttpd, т.е. имеет место пересечение 2 букв конца первого и начала второго слова. Но это мелочи. Больше для поисковиков, скорее.

  2. Maxime

    Более одной строки выводилось при chuncked transfer, когда каждый чанк предварялся набором зоголовков, отдаваемых CGI-скриптом.

    По хорошему весь aspell нужно переписывать, попутно отлавливая баги и оптимизируя по скорости, но на это нету времени 🙁

  3. ooptimum

    Нет, именно, что при http 1.0 поведение ничем не отличалось от chunked transfer'ов http 1.1. Возможно, я высылал не очень информативные примеры в этом смысле. Но то, что я получал несколько заголовков и на http 1.0 -- точно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *