For the moment, embed python sys.stdout & sys.stdin are replaced by pipes in order to catch all stuff sent to stdout/stderr.
On the PEP333 worker, this pipes are read, logged & flushed when the entrypoint function returns.
On the alternate IO worker, this pipes are polled by a cloned thread. As data becomes available, the thread read the pipe and log/send to libfcgi fetched data.
The PEP333 behavior has a major flow : if application send to much data to one pipe, the write call will block indefinitely (the worker should be killed by a watchdog).
The alternate IO worker behavior implies to clone as soon as FCGX_Accept calls returns (in order to be able to use the FCGX_PutStr function on returned streams…)
A simple solution to both problems is to create a libpyfcgi.IoOut classes, implementing a RawIO write only interface : when write* method is called, the data is sent where is should be (in log for PEP333, in log or to libfcgi for alternate IO workers).
Note : seems like a lot of stuff from IoIn can be factorised with IoOut class (see #13)…
For the moment, embed python sys.stdout & sys.stdin are replaced by pipes in order to catch all stuff sent to stdout/stderr.
On the PEP333 worker, this pipes are read, logged & flushed when the entrypoint function returns.
On the alternate IO worker, this pipes are polled by a cloned thread. As data becomes available, the thread read the pipe and log/send to libfcgi fetched data.
The PEP333 behavior has a major flow : if application send to much data to one pipe, the write call will block indefinitely (the worker should be killed by a watchdog).
The alternate IO worker behavior implies to clone as soon as FCGX_Accept calls returns (in order to be able to use the FCGX_PutStr function on returned streams...)
__A simple solution to both problems is to create a libpyfcgi.IoOut classes, implementing a RawIO write only interface : when write* method is called, the data is sent where is should be (in log for PEP333, in log or to libfcgi for alternate IO workers).__
Note : seems like a lot of stuff from IoIn can be factorised with IoOut class (see #13)...
For the moment, embed python sys.stdout & sys.stdin are replaced by pipes in order to catch all stuff sent to stdout/stderr.
On the PEP333 worker, this pipes are read, logged & flushed when the entrypoint function returns.
On the alternate IO worker, this pipes are polled by a cloned thread. As data becomes available, the thread read the pipe and log/send to libfcgi fetched data.
The PEP333 behavior has a major flow : if application send to much data to one pipe, the write call will block indefinitely (the worker should be killed by a watchdog).
The alternate IO worker behavior implies to clone as soon as FCGX_Accept calls returns (in order to be able to use the FCGX_PutStr function on returned streams…)
A simple solution to both problems is to create a libpyfcgi.IoOut classes, implementing a RawIO write only interface : when write* method is called, the data is sent where is should be (in log for PEP333, in log or to libfcgi for alternate IO workers).
Note : seems like a lot of stuff from IoIn can be factorised with IoOut class (see #13)…