FastCGI release: when running kcgi's FastCGI mode on nginx, processes
were being mysteriously killed under high load.
This was due to the end-point closing the connection before all data
was being read or written.
To wit, I now establish a difference (in FastCGI) between the
connection closing (which is a recoverable error) and the manager
killing the connection or the control socket exiting, which are not
Since most of this development was on Linux/ARM with nginx, the
sandbox for Linux has also been tooled up.
A big thanks to Elouan Pignet, who was kind enough
to diagnose the problem and provide access to his system for a fix,
including several failed attempts.
To this end (API change
when the system has exited.
is reserved for when the output channel
has closed (after parsing) and the current connection is no longer
The documentation has been updated for relevant functions.
While studying these code paths, make sure that a sequence of writes
or any of the
writing front-ends) won't fail if khttp_body(3)
wasn't able to
complete due to the connection closing.
Specifically, if the connection closes during khttp_body(3)
), the system will still expect headers.
Earlier, it would assert with subsequent khttp_write(3)
if the error
were not caught and the
In the modified behaviour, it will return
indicate that the system is out of state.
Merge a set of tutorial fixes from cyball
Allow the kutil_log(3)
This makes it possible to use these functions for consistent logging
without a request.