> -----Original Message----- > From: Pierre Joye [mailto:pierre....@gmail.com] > Sent: Wednesday, January 30, 2013 8:10 AM > To: Stas Malyshev > Cc: Zeev Suraski; PHP internals > Subject: Re: [PHP-DEV] ZTS - why are you using it? > > On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev <smalys...@sugarcrm.com> > wrote: > > Hi! > > > >> Python, for example, is thread safe by default. Extensions developers > > > > Doesn't Python have global engine lock? > > Right, but they do not give up thread safety. See "Thread State and the Global > Interpreter Lock" in: > > http://docs.python.org/2/c-api/init.html
Pierre, As Stas pointed out a global lock has very little to do with the topic of discussion here. What PHP is trying to do is *much* more ambitious, so ambitious that at least I concluded it's not an achievable goal. This has nothing to do with laziness, much like deprecating safe_mode wasn't about laziness - it was about facing reality. The Python approach is exceptionally lazy (in software development that's often a Good Thing), and can be implemented very quickly if we wanted to. It wouldn't help you one bit with your use cases, though. > The TS model in php should be redesigned in the next major version, instead of > simply giving it up. I don't mind that we redesign TS for the next version, with two key issues: 1. I'm not sure that relying on TLS (beyond what we already do on TSRM today) is feasible. That was the naďve approach that I first tried back in 1999 and ended up ditching since it wasn't suitable. The two main ones are: [a] limited TLS space (we have *lots* of globals) [b] Inability to access globals from another image (e.g.., you won't be able to access sapi_globals which belong to php5.dll from mysqli.dll). Point [b] is mentioned in the RFC that you referred to. Point [a] might have been solved over the course of the last decade. TSRM wasn't designed for fun, it was there to solve real problems that TLS did not solve. 2. I think it's not very good use of our time. Based on what I heard in this thread, I would give up right here and now on the goal of having PHP run in-process in multithreaded web server. The pros pale in comparison to the cons. I would *not* remove ZTS - this was never the point of this thread - but I would recalibrate people's expectations about it. It sounds as if it could be useful for advanced 'I know what I'm doing' use cases like long-running threaded processes, and may be useful for the future if we ever want to support threads within a single request - but that's about it. Based on the feedback on this thread, I think we should instruct users that using thread-safe versions of PHP is slower, and that actually putting thread-safe PHP inside a multithreaded server is not a very reliable solution. We should recommend FastCGI/fpm instead. We should do that tomorrow morning (figuratively speaking). Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
