|
osdir.com mailing list archive |
|
Subject: Re: threads extension - msg#00008List: php.pecl.develto chose librariesâ after all, again, I am talking about possibility to do so. about possibility to see problems of those libraries and try to fix those. etc. On 8/14/07, John Coggeshall <john@xxxxxxxxxxxxxx> wrote: > I'd believe him Alexey :) > > There's a lot of problems of running PHP itself in a threaded environment, > the most obvious is that third party libraries used are hit-and-miss in > their thread saftey. It's been a discussion that is at least 5 years old. > > John > > > -----Original Message----- > > From: Alexey Zakhlestin [mailto:indeyets@xxxxxxxxx] > > Sent: Tuesday, August 14, 2007 12:16 PM > > To: Shane Caraveo > > Cc: pecl-dev > > Subject: Re: [PECL-DEV] threads extension > > > > why not? :) > > does it bring some unexpected problem? > > > > I am thinking about application server. > > see: http://blog.milkfarmsoft.com/?p=51 > > > > On 8/14/07, Shane Caraveo <shane@xxxxxxxxxxx> wrote: > > > It was just an experiment, I was interested in seeing if it was > > > possible or not. I wouldn't bother trying to do threads in php. > > > Shane > > > > > > Alexey Zakhlestin wrote: > > > > What is the history behind > > http://pecl.php.net/package/threads extension? > > > > What stopped it from getting stable/released? > > > > > > > > > > > > > -- > > Alexey Zakhlestin > > http://blog.milkfarmsoft.com/ > > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ Thread at a glance:
Previous Message by Date: click to view message previewRe: threads extensionUnfortunately, this principle doesn't let php become truly universal language, while practically it can be such. I am not suggesting to get rid of current php-behaviour â it is perfectly fine for most of the cases. I am talking about POSSIBILITY to make long-running apps without changing language from php to something else. sometimes it is needed On 8/14/07, Rasmus Lerdorf <rasmus@xxxxxxxxxxx> wrote: > Alexey Zakhlestin wrote: > > why not? :) > > does it bring some unexpected problem? > > One of the main design principles behind PHP is the shared-nothing > perfect sandbox. It ensures that each request is discrete and > completely independent of any other request. This core principle allows > it to scale horizontally to handle massive loads. > > Obviously complex applications need a persistent datastore of some sort, > and sometimes that needs to be faster than a database, but in order to > keep the architecture manageable we need very clean and concise > interfaces between the core of PHP and these add-on mechanisms. > Threading is pretty much the opposite of a clean and concise interface > to our perfect sandbox. > > -Rasmus > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ Next Message by Date: click to view message previewRe: threads extensionOn 14.08.2007 20:50, Alexey Zakhlestin wrote: Unfortunately, this principle doesn't let php become truly universal language, while practically it can be such. It was never supposed to be universal language, it's designed to solve problems of those who develop(ed) it. -- Wbr, Antony Dovgal Previous Message by Thread: click to view message previewRe: threads extensionHi, if I recall right from my experiments with pthreads on C level inside an extension and memory allocated from Zend, there are problems. Zend, in debug mode, checks if the memory has been allocated by the same thread, that's for the e* family of functions. One gets tons of messages and has to resolve to the libc allocator to be able to share data between threads. Andrey Alan Knowles wrote: > Alexey Zakhlestin wrote: >> I want to get answers: >> how well did the code in CVS work? >> > from what I remember: > - thread include almost worked, although was a bit buggy in terms of > rejoining at exit. >> were there any technical problems which original authors couldn't >> solve at that time? >> > The whole issue of passing data between threads, and the fact that it > behaves completely differently to how you would expect threads to work > (eg. shared resources, etc.). Made the thing rather pointless.. Most of > this would be next to impossible to solve, given PHP's core design. > > You would need to significantly redesign the core engine to do things like: > - Fixed, flat, simple opcode store, that did not store any context > information. > - Scopes that could be accessed in a simple way, and locked etc. > > Hope this gives you a flavor of the issues.. > Regards > Alan >> after that I will be ready to ask for CVS account and start working. :) >> >> On 8/14/07, Antony Dovgal <antony@xxxxxxxx> wrote: >> >>> On 14.08.2007 22:30, Alexey Zakhlestin wrote: >>> >>>> Maybe it wasn'tÃâ But there are: >>>> 1) GUI programms written in PHP (GTK+) >>>> 2) Net-harvesters written in PHP (a lot of hand-made ones) >>>> 3) HTTP-server written in PHP (Nanoweb) >>>> >>>> etc. >>>> >>>> All of these would benefit from threads >>>> >>> I don't really understand what you're trying to prove here. >>> Do _YOU_ need it? If yes, then start working on it. >>> Or do you want someone else to do it for you? >>> >>> -- >>> Wbr, >>> Antony Dovgal >>> >>> >> >> >> > Next Message by Thread: click to view message previewthreads extension patch#1I am not sure if this mailing list allows attachmentsâ so, the patch is both attached to this message and is available online here: http://filez.indeyets.pp.ru/threads.diff these changes were required for a) compilation on macos-x 10.4.10 (gcc-4.0.1) b) elimination of bus-error in RSHUTDOWN looks like extension really works to some degree, but has a bunch of problems I will try to clean it up further -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ Loading Comments...
|
|
