Re: ZTS - why are you using it?

As a developer I really enjoyed that discussion, it was very informative for me. I'm always stuck with question which version of PHP to use. 2013/1/29 Zeev Suraski <zeev@zend.com>: >> -----Original Message----- >> From: Pierre Joye [mailto:pierre.php@gmail.com] >> Sent: Tuesday, January 29, 2013 2:19 PM >> To: Zeev Suraski >> Cc: Johannes Schlüter; PHP internals >> Subject: Re: [PHP-DEV] ZTS - why are you using it? >> >> On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski <zeev@zend.com> wrote: >> >> >> It is inter process sharing and is very expensive, nothing to compare >> > with shared >> >> memory within a single process, accross many threads. >> > >> > What are you basing that assertion on? Shared memory should have >> > identical performance to regular process memory. It's mapped in very >> > similar way. >> >> Testing maybe? > > Retest then, you've got it wrong. Shared memory (or memory mapped files > as they'd be on Windows) are simply memory, it's available to the process > in exactly the same way and while the OS does slightly different > book-keeping for it in how it populates the pages - it's negligible. > >> >> >> Miss the rest of my mail or? Current implementation is outdated >> >> >> and slow. >> >> > >> >> > That is true. Many modern compilers and environments provide >> >> > better support for thread local storages .... >> >> >> >> Exactly, or more exactly CRTs (libc, crt and the likes)> >> > >> > Can we stop arguing about the implementation >> >> No, we can't. The main reason of the bugs and performance issue is due > to the >> current implementation and how extensions developers have to deal with > it. It is >> not separable from discussing what could be the worst decision we ever > made, >> droping thread safety. > > Well, I'm not interested in discussing the implementation when the need > isn't clear to me. > For example, you could say that thread-safe PHP would be 2x faster. Or 2x > more memory efficient. Or will enable us to do XYZ which we otherwise > can't. > For now, an *utopian* ZTS mode would, at best, not give us anything. > Even if we put aside the performance/reliability issues - why would > someone want that mode over other modes? > >> > So far the only real use case that was brought up was for using >> > pthreads in a long-running app. I've yet to hear about a single real >> > reason of why someone would want to use it in web server context that >> > is not based on misconceptions or myths. >> >> Thanks, it is really nice to say something and being told that what has > been done >> is misconceptions or myths, especially if you gave up on thread safety > years ago >> within your company. That's all good, as long as it only affects your > company >> products and not PHP as a whole. > > Pierre, I'm sorry, but when you state something like '[shared memory] is > inter process sharing and is very expensive', there's no other way to > describe it other than a myth. Better theoretical performance is a > misconception. The best PHP performance/density available today is on > nginx, which couldn't be farther away from > multithreaded-PHP-in-process-arch. > > Even after what you just said, you've yet to bring up a single reason for > why one would want to use ZTS inside a web server context. You seem to > love ZTS with a vengeance but you can't quite explain why. My 'company' > didn't decide anything regarding ZTS. It was me, probably the person with > the most experience with ZTS back in the day, and it was probably much > more difficult for me than anybody else to realize that the ZTS approach > was the wrong path to go to as it was my baby project. > > BTW, for the love of [insert here], I'm not talking about killing thread > safety. It's useful for long running processes, and who knows, maybe in > the future we'll have threads inside PHP. But I *am* talking about > telling people that using ZTS in production is not recommended and that > they should be using FastCGI instead. > > Zeev > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Pozdrawiam, Damian Tylczyński