mendelgusmao
commented
13 years ago "STDOUT spurious data" problem solved with the use of Output Control.
After all tests and bug fixes, now all my effort are to develop StdIODriver and make the communication between front and backend bidirectional using pipes. Despite my lack of knowledge about pipelining, the problem is purely architectural.
Following the flux:
- Data is exported - *Driver::set()
- Backend is executed Runner::run()
I decided to leave Runner coupled to GhettoIPC and *Driver to be injected. They are unaware of other. What Runner does is simply to execute a command line passing the id of the exported file (or Memcache entry), but with StdIODriver it will not be so simple. Runner must get data from StdIODriver in order to pipe it to backend process.
Actually, Runner is receiving a reference of GhettoIPC. As in PHP 4, there is no real encapsulation, so Runner can access GhettoIPC properties, and a Driver is contained into it. A very ugly approach, because I'm coupling Runner and Driver.
(more to be written)
Until now, the spawn of new backend instances is being done by a poor shell_exec command. It means - no control of the spawned proccess and, hypotheticaly, chances of leaving zombie processes running if they stuck and the frontend process achieves its maximum execution limit.
I am thinking about a Runner class who might take control of the execution of the backend. It will be a wrapper with validations and ability to send triggered errors to Bridge class.
shell_exec() will be replaced by proc_open(), as it has ways to deal with STDIN/STDOUT before preparing the framework to use STDIN/STDOUT as Driver (the new class StdIODriver). Once this issue is resolved, there is one more problem before turning StdIODriver the default driver method.
In PHP, STDOUT is the default way out of echo, print and everything else that makes information be showed in the screen. Using FileDriver, for example, the serialized data is written to a file by frontend, unserialized by backend, rewritten by backend with the serialized data returned by the Calls and unserialized by the frontend. This method is granting that no spurious data will corrupt the serialization file.
So, what can happen if Ghetto RPC uses STDOUT, the same way PHP uses by default to show information? If any error occurs, it will be prepended to serialization, causing deserialization errors in frontend, screwing up everything. An innocent debug echo or anything in the backend code raising any E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING (the errors that cannot be handled by set_error_handler()) will cause it. That's why I think StdIODriver is dangerous despite its speed. For now, my favorite is FileDriver, because in my tests it showed to be 10-12 times faster than... believe it: Memcache!
Maybe output buffering in the backend and some validation in frontend could ensure reliabiality adopting StdIODriver.