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 theta...@php.net - http://www.php.net NSAPI SAPI developer Bremen, Germany > -----Original Message----- > From: Terry Ellison [mailto:ellison.te...@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? > > 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. > > -- > PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: > http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
