Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68565
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
Message-ID: <5212423A.4000801@gmail.com>
Date: Mon, 19 Aug 2013 17:05:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Which OSs and SAPI should PHP 5.6 support?
From: ellison.terry@gmail.com (Terry Ellison)

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 
5.6, which SAPIs are supported, and a matrix of which SAPIs are 
supported on non-threaded and build TSRM variants.

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?

Likewise in the Zend, TSRM, ext/opcache ... sources, there is 
conditional code dependent on BeOS, __sgi, __osf__,  __IRIX__, NSAPI, 
PI3WEB, GNUPTH(*), OS_VXWORKS,  etc. as well as obsolete BSD versions -- 
OSs that are no longer actively supported.  Again I ask the Q how and 
when are these tested and if not then shouldn't we retire this support?

Part of my reasons for asking this is work in preparation for OPcache 
issue #118 -- Transparent SHM reuse.  Doing this with robustly with good 
performance characteristics -- for *all* currently referenced OSs -- is 
a pain.  Reviewing a range of other best-of breed packages which use 
shared SMA-based resources, it seems to me that the memcached approach 
is the cleanest:  it uses the POSIX APIs and supports any OSes which 
support these APIs.  If we limited TSRM and OPcache support at PHP 5.6 
to two code variants, POSIX + WIN32, surely this would still cover all 
the major supported OSes?

//Terry Ellison

(*) GNU threads is still supported but it prevents utilisation of SMP 
systems and there is a minimal performance differences from POSIX 
threads on a single processor system.