<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>

<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>

<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++)

}
}

$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>

<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>

<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>

<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>

<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>

<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>

<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>

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