Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:68567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 188.138.97.18 as permitted sender)
To: <internals@lists.php.net>,
	"'Terry Ellison'" <ellison.terry@gmail.com>
References: <5212423A.4000801@gmail.com>
In-Reply-To: <5212423A.4000801@gmail.com>
Date: Mon, 19 Aug 2013 18:20:15 +0200
Message-ID: <01dc01ce9cf8$11049ae0$330dd0a0$@php.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLe5Zr99olll549dCh8ICTHrXYPrZd8I78g
Content-Language: de
Subject: RE: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
From: thetaphi@php.net ("Uwe Schindler")

Hi,

I would update NSAPI as I always did, there were just no new bugs and =
code is very stable (to the extend of "stableness" of multithreaded =
SAPIs). It is still also in use on some of my servers, so I would still =
help support it. At the moment I did not follow recent commits to =
SAPI-related code, so I have to closer look into it. Are there any RFCs =
related to changes coming in 5.6 for OPcache?

Unfortunately I did not do any commit since we moved away from SVN...

Uwe

-----
Uwe Schindler
thetaphi@php.net - http://www.php.net
NSAPI SAPI developer
Bremen, Germany

> -----Original Message-----
> From: Terry Ellison [mailto:ellison.terry@gmail.com]
> Sent: Monday, August 19, 2013 6:05 PM
> To: internals@lists.php.net
> Subject: [PHP-DEV] Which OSs and SAPI should PHP 5.6 support?
>=20
> 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.
>=20
> 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.
>=20
> 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?
>=20
> 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?
>=20
> 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?
>=20
> //Terry Ellison
>=20
> (*) 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.
>=20
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, =
visit:
> http://www.php.net/unsub.php