Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:89690
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender)
To: internals@lists.php.net
References: <CAEZo+geVzjSrGhUhpy7oJEX5CddE1=L3sNBS7CTPvwAM0EQ1hA@mail.gmail.com>
Message-ID: <5665536E.5060702@gmail.com>
Date: Mon, 7 Dec 2015 09:37:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <CAEZo+geVzjSrGhUhpy7oJEX5CddE1=L3sNBS7CTPvwAM0EQ1hA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Why PHP 7 yield from still single thread and blocking
 thread?
From: rowan.collins@gmail.com (Rowan Collins)

Netroby wrote on 07/12/2015 07:05:
> As the RFC said.
> https://wiki.php.net/rfc/generator-delegation
> The defining feature of Generator functions is their support for
> suspending execution for later resumption. This capability gives
> applications a mechanism to implement asynchronous and concurrent
> architectures even in a traditionally single-threaded language like
> PHP. With simple userland task scheduling systems interleaved
> generators become lightweight threads of execution for concurrent
> processing tasks.
>
> I wrote a small test. to see if it really concurrent processing any tasks.
> the result looks bad. Still single blocking thread.

You might be interested in this recent thread: 
http://marc.info/?t=144342922700001&r=1&w=2 Particularly the discussion 
of parallel vs asynchronous execution here: 
http://marc.info/?l=php-internals&m=144354107223549&w=2

Generators / co-routines can be useful when working with asynchronous 
APIs - that is, functions which start a background task and notify when 
it is completed - but they do not magically make sequential code 
parallelizable. Threads - true parallel execution - are much more 
complex to implement, because of the need to access shared resources in 
a safe way.

So there is nothing surprising in your example not running in parallel: 
"yield" does not start a new thread, and "sleep" is not an asynchronous 
API. If instead of sleep you called an asynchronous function, such as a 
MySQL call set to asynchronous mode, you would indeed see your 
co-routines running concurrently, as each waited for its respective 
query result to come back from the database.

Hope that helps point you in the right direction to better understand 
what's going on.

Regards,
-- 
Rowan Collins
[IMSoP]