Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Executor behavior #1

Open
eLod opened this issue Jul 20, 2011 · 2 comments
Open

Executor behavior #1

eLod opened this issue Jul 20, 2011 · 2 comments
Assignees

Comments

@eLod
Copy link
Owner

eLod commented Jul 20, 2011

the executor's main goals are:

  • saving state, e.g. preserving variables, defined functions/classes, etc. from previous inputs.
  • handling errors, e.g. handle fatal errors in input code without terminating the console process

there are 2 main alternatives to execute (input) code in php

  • internal: include, eval, etc.
  • external process: exec, etc.

with internal commands saving state is much easier as variables could be stored (without the need of passing from one process to another), functions and classes will be defined in the global scope (available in the console process). using an external process on the other hand requires some kind of serialization to pass data from the external process back to the console process (so that it can pass it to the next external process). this poses a few difficulties, like serializing (and unserializing) user defined and framework objects (like models and collections, possibly controllers, etc.) or closures (PHP has some limiting functionality to 'inspect' closures, but it boils down to parsing back the closure from the file), not to mention functions/files.

error handling is the other way around, it is almost trivial with external processes and somewhat impossible with internal commands (there are errors which cannot be 'catched'/caught and will terminate the console process).

it seems that we can't have both and given the complexity of serializing/unserializing i think giving up the error handling is the better choice, but i created this ticket to elaborate on the issue

@nateabele
Copy link

Actually, passing state and things like closures to an external process is quite easy, and involves no serialization of any kind. In fact, it can be done in the same way it's handled for saving state now: by having the main process write to a PHP file, and telling the executor what file to include.

@ghost ghost assigned eLod Aug 3, 2011
@eLod
Copy link
Owner Author

eLod commented Aug 3, 2011

I extracted the core functionality (with a working external executor, see ExternalExecutor). However there's still a little 'gimmick': i use a special string (written to STDOUT by the external process, read by the main one, see line 47 and line 169) to know if the execution ended successfully. I tried to get around it with other techniques but i couldn't come up with a satisfying solution. Do you have any idea, or do you think relying on this is adequate?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants