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)...
yannweb
adicionou esta issue para o marco BETA version5 anos atrás
yannweb
mudou título de Duplicate libpyfcgi.IoIn implementation for write only streams para Duplicate libpyfcgi.IoIn implementation to write only streams5 anos atrás
yannweb
mudou título de Duplicate libpyfcgi.IoIn implementation to write only streams para Duplicate libpyfcgi.IoIn implementation to write using streams only5 anos atrás
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)…