Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68582
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender)
Message-ID: <52138C87.5060705@gmail.com>
Date: Tue, 20 Aug 2013 16:34:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?Sm9oYW5uZXMgU2NobMO8dGVy?= <johannes@schlueters.de>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <5212423A.4000801@gmail.com> <1376941908.4056.42.camel@guybrush>
In-Reply-To: <1376941908.4056.42.camel@guybrush>
Content-Type: multipart/alternative;
 boundary="------------060307030903060005020109"
Subject: Re: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
From: ellison.terry@gmail.com (Terry Ellison)

--------------060307030903060005020109
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Johannes,
Thanks, but I'll make some responses
> On Mon, 2013-08-19 at 17:05 +0100, Terry Ellison wrote:
>> By way of a background.  I've been doing a review of the exting code
>> base looking at how to establishing a roadmap extend OPcache
>> functionality across all supported OSes and SAPIs.  And this raises a
>> supplementary Q: which OSs and SAPIs should we be supporting for PHP 5.6
>> anyway?  I would be interested in the  views of the dev team on this.
>>
>> It would be good to agree a list of which OSs are to be supported at PHP
> The short version is quite simple: PHP supports everything and nothing.
>
> Our aim is to be portable and have it running anywhere somebody has a C compiler and the required libs. On the other hand, in open source spirit, we promise nothing.
>
> In reality I expect that most developers use Linux and we have a active Windows fraction.
>
> If we promise support for any platform it has two direct consequences:
>   - We have to test and verify it
>   - We immediately disappoint people who run PHP successfully on "edge"
>     platforms
>
> And then more longterm consequences:
>   - Mind new platforms
>   - Continuous discussions about adding support for new platforms
>
> The current model otoh works quite well.
I understand the nuances of what "support" means in the FLOSS world, but 
at some level we also be able to look at ourselves in the mirror and say 
that are releases are at a standard that we can feel comfortable with.  
As you say, we have an established Linux base as well as some Windows.  
I would also add a solid BSD user base (FreeBSD, NetBSD, OSX, etc.).   
(Maybe I'd include Solaris, but it's on the way out given Oracle's 
position.)

But what about all of the other obsolete platform code?  We ship this 
with our PHP source, version after version, knowing that its never being 
exercised or tested.  Surely if and when we want to improve PHP's 
platform support and architecture, then this stuff is like chains 
dragging at out feet.  For example, I know how to make OPcache work well 
for other SAPIs such as cli, mod_fcgid, etc. but only if I can refactor 
the necessary chunks and only for POSIX and Win32 which covers the 
platforms we've just discussed; worrying about of the other flavours 
that I could never test just gives me too much brain ache, but I can't 
propose a code refactor if I don't know what to do with it.

PHP (unlike some language alternatives) seems to be doing little to 
improve general performance, and the discussions related to performance 
on this DL are almost non-existent.
>> 5.6, which SAPIs are supported, and a matrix of which SAPIs are
>> supported on non-threaded and build TSRM variants.
> I myself would kill TSRM, but others have reasons to disagree ;-)
>
> In general: There are features which are dependent on operating system, 3rd party library or TSRM. This is fine. Based on my statement from above I claim (again, there are people who disagree for reasons I follow less than the general case above) that nobody who cares about performance uses TSRM, as such an opcode cache is not needed in such environments.
Yes, if the Zend engine had first been developed for Windows, then it 
would have supported proper multi-threading from Day 1.  It wasn't, so 
TSRM is a cludge to achieve this.  Dmitry made the comment somewhere 
that enabling TSRM incurs a ~20% performance hit, which I can believe, 
but as far as I can see, WIN32 implementations rely on it for scaling.

Looking at fpm, cgi, etc. all of the SAPIs which rely on a master/child 
process hierarchies for scaling use fork, and they all have a big 
#ifndef ZEND_WIN32 around this code.  OK, CreateProcess incurs more 
startup overhead than forking and there are other startup issues to 
address relating to acquisition of context, but I've written serious 
realtime systems for WIN32 in the past that performed well without 
threads. So I am not sure why this is the case.

However the lack of OPcode caching on complex apps typically halves 
system throughput.  Most if not all admins care about that sort of hit.
>> Examples of what I am talking about are SAPIs with no clear evidence of
>> active support (I've listed the last non-bulk change in brackets to give
>> a measure of the level of support):
>>       aolserver (2008), caudium (2005), continuity (2004), nsapi (2011),
>>       phttpd (2002), pi3web (2003), roxon (2002), thttpd (2002),
>>       tux (2007), webjames (2006)
>> I realise that some of these may still be actively used with a user
>> community out there wanting to track current versions, and this is just
>> a case of "if ain't broke..."  However, I do wonder when some of these
>> were actively maintained and routinely tested against the current
>> versions at release -- and if not then perhaps PHP 5.6 is the correct
>> point to retire them from the source tarball and configure options?
> First thing to note is that the SAPI layer is one of the most stable ones. So old SAPIs most likely work.
> Secondly: Yes some of them almost certainly can go, when we discussed this last (~10 years ago) an issue was that we have no good place to put these. For extensions we have PECL where people can try if they get it working ... getting SAPIs work from out of tree is not as easy ...
How about the great bit bucket?  Surely there's no point in distributing 
a SAPI if we have no maintainers or sysadmins left who are willing to 
move their legacy apps on their out-of-support OSs, from whatever 
version they are running -- say PHP 5.2 -- to the current version.

--------------060307030903060005020109--