Re: [PATCH] Deprecate use of stdio

From: Date: Fri, 02 May 2003 15:38:11 +0000
Subject: Re: [PATCH] Deprecate use of stdio
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-1164@lists.php.net to get a copy of this message
I've been playing with sfio on Solaris quite a bit recently and I've had our site working on iPlanet with sfio for a couple of weeks. Seems to be doing okay so far with something between 4.3.1 and 4.3.2. Getting sfio to link was a bit of pain in the arse at first, but it came down to a couple of simple LIBS arguments to get it going. As you say, fixing the problem at the root would be preferable, but sfio might be a decent intermediary step. I can test the patches and such on Solaris 8 SPARC, and if you (or anybody who needs it, within reason of course) would like access to a Solaris shell, I can arrange it. (It's slightly limited by a 300 MB quota, but that's pretty much it.) J Sascha Schumann wrote: > The following patches are aimed at deprecating the use of > stdio by the script lexer in PHP 4, because certain stdio > libraries impose restrictive limits on the number of open > handles*. > > The patches have been split functionally for the benefit of > the reviewer. > > Patch 1 adds a stream interface which fills in a > zend_file_handle. This is simply a modified copy of the > open_as_file function. > > Patch 2 adds zend_open() which expects the implementation to > fill in a zend_file_handle. > > Patch 3 makes PHP supply a zend_open implementation. > > Patch 4 modifies the lexer skeleton so that it can read using > POSIX functions and stdio. It also makes > open_file_for_scanning use zend_open. > > * Background: Even the most modern Solaris ships with a stdio > library which cannot handle fds over 255. This severely > limits any web server which may open more than 255 fds per > process, because it won't be able to parse PHP scripts > anymore. > > I've evaluated integrating sfio into the build process, but > as it turns out, a full and complete integration would be a > lot more complex than addressing the issue up-front. > > - Sascha

« previous php.internals (#1164) next »