Zend Framework: Zend_Console_Process Component Proposal
| Proposed Component Name | Zend_Console_Process |
|---|---|
| Developer Notes | http://framework.zend.com/wiki/display/ZFDEV/Zend_Console_Process |
| Proposers | Ben Scholzen Zend Liaison Ralph Schindler |
| Revision | 1.1 - 26 April 2008: Initial proposal (wiki revision: 10) |
Table of Contents
1. Overview
Zend_Console_Process is a Processing component which simplifies the use of multiple pseudo-threads. This component can be used to accomplish multiple tasks at once. However, this component is limited to Unix bases systems, since Windows does not support the pcntl_* functions.
2. References
3. Component Requirements, Constraints, and Acceptance Criteria
- This component will allow running as many pseudo-threads parallely as possible.
- This component will allow communication between parent and child at any time.
- This component will keep an eye on zombie-processes.
- This component will only work on unix-like (Linux, BSD, Mac/OSx) systems with PHP CLI
4. Dependencies on Other Framework Components
- Zend_Exception
- pcntl_ functions
- shmop_ functions
5. Theory of Operation
The component must first be extended by another class, which implements the abstract method _run. After intantiation, the start() method can be called, which starts the new thread. While the thread is running, the parent can check via the isRunning() method, if the thread is still alive. To kill the process, the stop() method can be called.
6. Milestones / Tasks
- Milestone 1: [done] Working prototype checked into http://zend.svn.dasprids.de/
- Milestone 1: Proposal appprovement.
- Milestone 3: Unit tests exist and work.
- Milestone 4: Prototype and unit tests are checked into Incubator.
- Milestone 5: Initial documentation exists.
7. Class Index
- Zend_Console_Process_Abstract
- Zend_Console_Process_Exception
8. Use Cases
| UC-01 |
|---|
9. Class Skeletons
Yeah in the case of multiple requests at the same time, non-blocking socket conenctions are fine. but when evaluation the data parallely, you actually need threads.
Not really... You aren't supposed to be using PCNTL through a server, and only CLI based. To me, it seems that implementing one of my above links is actually more worth-while and would help out better.
Sure, you can't process the data in parallel, but in the case of whois / web services, the longer time is probably going to be sent waiting for the requests you sent to come back.
This also means, that adding this to something like Zend_Whois makes it unable to function in a web environment, you'd have to use it from command line.
Well there's also a possiblity to implement threading support for web enviorments, thought it would be quite tricky.
You mentioned the real negative point on this proposal already.
IT DOES NOT SUPPORT WINDOWS.
As this is about 50% of the community it would also mean that any component which depends on this one, as you proposed in favor of Zend_Whois for example, would no longer work on windows systems.
Do we really want to lock out 50% of our community ?
In my opinon any component which is integrated has to support nix and win systems.
I see this really problematic.
50% is surely not the server-base, maybe 5% or so, but not more.
So depending on your opinion that windows systems are not used around the world you want only to support unix systems ?
I think that your opinion is not right... several small or even medium based companys are driving their own servers based on win2003 or later.
But ok... we do not have to support them, because they could buy a server where ZF would work.
Is this really your opinion ?
Not to support Win* systems because only 5% of ZF customers are using them ?
If that's your opinion I really have to disagree to this component for the core.
What do you think about adding a class Zend_Threading_Pool to simplify UC-01 to somethink like
-----------------------------------------------------------------
Anyway, I think core components should work on windows, unix as well as mac.
i just noticed i can't edit my comment. maybe we can solve the windows problem by simply make this component single-threaded on windows. using this component on windows wouldn't give any benefits but wouldn't break any components using this extension.
Indeed, that would be a good solution. *nix systems (Linux, Mac, BSD, etc.) could then benefit from the advantage of multi-threading, but compontents which depent on Zend_Threading wouldn't break on Windows.
Although this is an interesting idea, it isn't safe on a Web server. According to the PHP documentation,
Process Control should not be enabled within a web server environment and unexpected results may happen if any Process Control functions are used within a web server environment.
I think a name like Zend_Console_Process would more accurately reflect its purpose. Now, if it had that name, and the constructor threw an exception on Windows, I would give it a thumbs up. ![]()
Or, not necessarily throw an exception, but perform the action in serial. Ah, Daniel Freudenberger already mentioned that.
I like the direction of the proposal in general to simplify forking and IPC. However there should be two components. One for IPC and one for process management. The first could be reused in the process management component. Btw: method names containing more than a verb and a noun are an indicator that and internally solved part should be exposed as its own API as you the method does not explain its sense through itself and the class it belongs too but needs further clarification (see _writeIPCSegment() vs. setVariable()).
I really like this proposal!
But I would like to propose additional features following the Java Thread class, that this proposal is tightly following ![]()
the first two build on the assumption though, that static variables can also be used as shared memory variable storage.
1.) some synchronising or "hold on until" mechanism that allows to segment certain parts with a name and all Threads are only allowed to execute this block once a time, like the Java synchronized keyword.
Example:
if(Zend_Console_Process::synchronize('Block_name'))
Where Zend_Console_Process::synchronize might be a static method setting a static class variable Zend_Console_Process::$_synchronize_block['Block_name'] = true or something like that. Or given the Pool example above, the Pool Class would manage the execution blocks locks via a second shared memory variable that handles this feature.
2.) a Static method Zend_Console_Process::activeCount() returning the number of currently active pseudo-threads. The method $thread->isRunning() is working for a small number of threads, but given a larger number of threads its useful to be able to check the number of active threads via one method only.
3.) Implement an interface "Zend_Console_Process_Runnable" which thread classes can alternativly extend (Zend_Console_Process_Abstract inherits from this interface too). Allow the Zend_Console_Process Constructor to take an instance of the type Runnable, calling $this->obj_of_type_runnable->run() when start() is called instead of $this->run().
This way it is possible to use an Object as Thread instance, that inherits program logic from another class than Zend_Console_Process_Abstract.
| Zend Official Response This proposal is accepted to Extras Incubator for development. Notes:
|
ZF Home Page
Code Browser
Wiki Dashboard
Interesting, but you don't need pcntl or actual threads to make multiple requests at the same time (i.e. your Zend_Whois comment about querying multiple servers).
In those 2 cases, what really should be done is implementing some type of curl or socket adapter that allows for multiple requests. Check the following: