Обнаружил баг в mod_ssl от апача (т.е. он там давно, просто на сайте он обнаружился), разработчикам mod_ssl он, кажется, по барабану. Как починить, сам сообразить пока не могу. Sucks...
А асинхронный обработчик free и не делает. Он делает стандартный close_connection, а уж close_connection, вызывает hook из mod_ssl, который обязан вызывать free. Можно, конечно, close_connection вообще не делать, но тогда, боюсь, timeout перестанет работать - в write на уровне апача управление не вернётся, пока write нижнего уровня не вернёт чего-то осмысленного, а оно, судя по таймауту, ничего возвращать не собирается. Можно попробовать закрыть connection наполовину - т.е. сокет убить, а всё остальное оставить и положить какой-нибудь флажок, чтобы закрыть его потом, наверху. Надеюсь, при убитии сокета SSL из read/write выпадет и мест, где этот флажок придётся проверять, не слишком много.
Почитай Signal FAQ из RU.UNIX.PROG. Там написано что можно делать из обработчиков сигналов, и что из него делаеть не следует. Видимо, разработчики mod_ssl этого документа не читали. Вообще обработчик сигнала нужно ставить так, чтобы он системный вызов write прерывал. И close_connection ставить когда write вернет соответствующий код ошибки.
У апача там, вероятно, дело в том, что по таймауту там надо делать разные нетривиальные вещи, которые в код ошибки не запихнуть. А проверять каждый раз после ap_write, а не произошёл ли таймаут, им, вероятно, было лень.
no subject
Можно попробовать закрыть connection наполовину - т.е. сокет убить, а всё остальное оставить и положить какой-нибудь флажок, чтобы закрыть его потом, наверху. Надеюсь, при убитии сокета SSL из read/write выпадет и мест, где этот флажок придётся проверять, не слишком много.
no subject
Видимо, разработчики mod_ssl этого документа не читали. Вообще обработчик сигнала нужно ставить так, чтобы он системный вызов write прерывал. И close_connection ставить когда write вернет соответствующий код ошибки.
no subject