Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47756
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <4BB682D2.20104@zend.com>
Date: Fri, 02 Apr 2010 16:50:42 -0700
Organization: Zend Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: internals@lists.php.net
CC: 'Andi Gutmans' <andi@zend.com>
References: <1941231697.20100401163215@gmail.com> <g2i469956791004011604v210ad50dx89b65cd0d731cea7@mail.gmail.com> <698DE66518E7CA45812BD18E807866CE03FA7EFF@us-ex1.zend.net>
In-Reply-To: <698DE66518E7CA45812BD18E807866CE03FA7EFF@us-ex1.zend.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] php and multithreading (additional arguments)
From: stas@zend.com (Stanislav Malyshev)

Hi!

> I think that if we were ever to implement threading we would be best off
> to enable spawning worker threads that have their own context with no
> shared data (and therefore no requirement for locking). We could then
> have a message passing API between the threads.

No shared data requires quite new development paradigm though. Imagine 
you have big application, say, using some Big Framework, that needs to 
do some mysql queries in parallel. Now what happens is:
1. You can't really just start a thread and run a query whenever you 
wish to, because mysql connection is probably defined by configs that BF 
is managing, so you'd have to either create a separate "query server" 
thread which would keep the connection or open connection anew each time.
2. You can't use objects or anything more complex than an array between 
threads, since sharing objects means sharing classes and methods, which 
means sharing data stored there.
3. You still have problems with libraries keeping global state, and many 
do and even don't bother to tell you about it or provide any means to 
manage it (e.g. ICU).
4. The overhead of keeping whole set of globals per thread will still be 
there. Which btw means starting a thread would imply whole RINIT 
process, along with allocating globals, etc. which may not be as fast as 
you'd expect.

I think it may be worth trying, but for that we need some good use-case 
and try to see how it would work out with this use-case.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com