On Sun, 23 Feb 2003, Wez Furlong wrote:
> This double seeking is most probably due to the fact that the stdio
> layer does one set of seeking, whereas streams needs to do another.
> 
> This can be solved by moving away from using stdio for streams, and just
> using the "raw" descriptors instead.  (already made a start on this in
> PHP 5).

I had a closer look at this.  The seeks are not coming from the stdio 
layer, they are coming directly from PHP.  The first, SEEK_CUR +0 comes 
from an ftell() call here in _php_stream_fopen_from_file():

    if (stream) {
        if (self->is_pipe) {
            stream->flags |= PHP_STREAM_FLAG_NO_SEEK;
        } else {
            stream->position = ftell(file);
        }
    }

We should be able to skip that ftell() call on a script or include file we 
have just opened, right?

And here is the backtrace for the second one:

#0  0x202e6c0f in lseek () from /usr/lib/libc.so.4
#1  0x203ef154 in php_stdiop_seek (stream=0xd640c, offset=0, whence=0, 
newoffset=0x9fbfdcbc)
    at /homes/rasmus/php4/main/streams.c:1493
#2  0x203ef868 in _php_stream_cast (stream=0xd640c, castas=-1073741824, 
ret=0x9fbfdcf0, show_err=8)
    at /homes/rasmus/php4/main/streams.c:1952
#3  0x203f04d6 in _php_stream_open_wrapper_as_file (path=0xddad8 
"/home/y/share/htdocs/test.php", mode=0x2043a223 "rb",
    options=141, opened_path=0x9fbff328) at /homes/rasmus/php4/main/streams.c:2506
#4  0x203e3b4e in php_fopen_wrapper_for_zend (filename=0xddad8 
"/home/y/share/htdocs/test.php", opened_path=0x9fbff328)
    at /homes/rasmus/php4/main/main.c:727

The php_stdiop_seek() does a direct lseek() call.  I don't really see why
this is needed either at this point.  In
_php_stream_open_wrapper_as_file() what are you trying to guard against
with that stream_cast call?

    if (php_stream_cast(stream, 
PHP_STREAM_AS_STDIO|PHP_STREAM_CAST_TRY_HARD|PHP_STREAM_CAST_RELEASE,
                (void**)&fp, REPORT_ERRORS) == FAILURE)
    {
        php_stream_close(stream);
        if (opened_path && *opened_path)
            efree(*opened_path);
        return NULL;
    }

We have already stat()'ed the file to death.  We know it is there, that we 
are allowed to open it, etc.  What could go wrong that the open call just 
above it wouldn't have caught?  Is it just a case of getting too general 
and we need a special-case simpler function for the most common operation 
of simply opening script files?

-Rasmus


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to