Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

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: 12)

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

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Apr 26, 2008

    <p>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).</p>

    <p>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:</p>

    <ul>
    <li><a class="external-link" href="http://netevil.org/blog/2005/may/guru-multiplexing">http://netevil.org/blog/2005/may/guru-multiplexing</a></li>
    <li><a class="external-link" href="http://www.rustyrazorblade.com/2008/02/20/curl_multi_exec/">http://www.rustyrazorblade.com/2008/02/20/curl_multi_exec/</a></li>
    <li><a class="external-link" href="http://us2.php.net/curl_multi_exec">http://us2.php.net/curl_multi_exec</a></li>
    </ul>

    1. Apr 26, 2008

      <p>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.</p>

      1. Apr 26, 2008

        <p>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.</p>

        <p>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.</p>

        <p>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.</p>

        1. Apr 26, 2008

          <p>Well there's also a possiblity to implement threading support for web enviorments, thought it would be quite tricky.</p>

        2. Apr 26, 2008

          <p>However, Zend_Threading may also be limited as CLI-only component.</p>

  2. Apr 26, 2008

    <p>You mentioned the real negative point on this proposal already.</p>

    <p>IT DOES NOT SUPPORT WINDOWS.</p>

    <p>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.</p>

    <p>Do we really want to lock out 50% of our community ?<br />
    In my opinon any component which is integrated has to support <strong>nix and win</strong> systems.<br />
    I see this really problematic.</p>

    1. Apr 26, 2008

      <p>50% is surely not the server-base, maybe 5% or so, but not more.</p>

      1. Apr 26, 2008

        <p>So depending on your opinion that windows systems are not used around the world you want only to support unix systems ?</p>

        <p>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.</p>

        <p>But ok... we do not have to support them, because they could buy a server where ZF would work.</p>

        <p>Is this really your opinion ?<br />
        Not to support Win* systems because only 5% of ZF customers are using them ?</p>

        <p>If that's your opinion I really have to disagree to this component for the core.</p>

        1. Apr 26, 2008

          <p>Please read all new comments. As Daniel mentioned below, I could integrate a fallback-mode for Windows. As mentioned some commetns above, it's anyway CLI only, so it can't be used for Zend_Whois as web-compontent anyway (that was my fault in the component's description).</p>

  3. Apr 26, 2008

    <p>What do you think about adding a class Zend_Threading_Pool to simplify UC-01 to somethink like </p>
    <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
    class ThreadingTest extends Zend_Threading_Abstract
    {
    protected function _run()
    {
    for ($i = 0; $i < 10; $i++)

    Unknown macro: { sleep(1); }


    }
    }

    $pool = new Zend_Threading_Pool();
    $pool->add(new ThreadingTest(), $autoStart);
    $pool->add(new ThreadingTest(), $autoStart);
    $pool->join();

    echo 'All threads completed';
    ]]></ac:plain-text-body></ac:macro>
    <p>-----------------------------------------------------------------</p>

    <p>Anyway, I think core components should work on windows, unix as well as mac.</p>

    1. Apr 26, 2008

      <p>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.</p>

    2. Apr 26, 2008

      <p>The Threading pool is a really nice idea.</p>

  4. Apr 26, 2008

    <p>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.</p>

  5. Apr 26, 2008

    <p>Although this is an interesting idea, it isn't safe on a Web server. According to the PHP documentation,</p>

    <blockquote>
    <p>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.</p></blockquote>

    <p>I think a name like <code>Zend_Console_Process</code> 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. <ac:emoticon ac:name="smile" /></p>

    1. Apr 26, 2008

      <p>Or, not necessarily throw an exception, but perform the action in serial. Ah, Daniel Freudenberger already mentioned that.</p>

    2. Apr 26, 2008

      <p>Yeah, that really makes sense, I will rename the proposal now.</p>

  6. Apr 27, 2008

    <p>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()).</p>

  7. Jun 15, 2008

    <ac:macro ac:name="unmigrated-wiki-markup"><ac:plain-text-body><Unable to render embedded object: File ([CDATA[I really like this proposal) not found.

    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')) {
    // do stuff
    }

    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.]]></ac:plain-text-body></ac:macro>

  8. Jun 23, 2008

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Official Response</ac:parameter><ac:rich-text-body>

    <p>This proposal is accepted to Extras Incubator for development.</p>

    <p>Notes:</p>
    <ul>
    <li>Name should be changed to ZendX_Console_Process_Unix to reflect the Unix only nature</li>
    </ul>

    </ac:rich-text-body></ac:macro>

  9. Jul 03, 2008

    <p>There is a bug on line ~360 of your working prototype. ITs in the else condition of the start() method where it says $this->_running = true; where it should be $this->_isRunning = true;</p>

    1. Oct 16, 2008

      <p>Thanks for the hint Beberlei. I just moved ZendX_Console_Process_Unix to the extras incubator. Probably your jQuery component won't be alone in 1.7 <ac:emoticon ac:name="smile" /></p>

  10. Jan 12, 2009

    <p>Hello,<br />
    is this proposal always up and moving on ? Because I actually need something close, and i wonder if you would like any help <ac:emoticon ac:name="wink" /></p>

  11. Jan 12, 2009

    <p>We're using this and it's working very well so far. You can find it in ZendX or extras.</p>