Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » zend_stream_fixup »

zend_stream_fixup

php.internals

Stanislav Malyshev

21 years ago
Can somebody explain me what zend_stream_fixup() function does? I see that it I give it ZEND_HANDLE_FP it converts it to ZEND_HANDLE_STREAM, but the handle of the stream does not become php_stream *, it still is FILE *. Does it mean that when I have ZEND_HANDLE_STREAM, the handle basically can be both FILE * and php_stream *? How can I distinguish between these situations?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Wez Furlong

21 years ago
The idea is that the zend engine should only call the functions in zend_stream.c to access the script input. The fixup function is designed to promote FILE* or file descriptors up to something compatible with its stdio stream reading functions. Filenames are handed out to PHP and opened up using the streams layer. The rule for the fixup function is that it either errors out, or sets up the zend_file_handle so that zend_stream_XXX functions will work. --Wez. On Wed, 9 Mar 2005 12:32:54 +0200 (IST), Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

21 years ago
WF>>The idea is that the zend engine should only call the functions in WF>>zend_stream.c to access the script input. The fixup function is But file_handle is not used only for input. There are a lof of other things that can be done with handle. Getting stat, for example, or seeking. It's possible to do it with FILE * and with php_stream, but not with the result of the fixup function. Actually, after fixup function it is impossible to do anything but read and close with the handle. I think it's very wrong. WF>>designed to promote FILE* or file descriptors up to something WF>>compatible with its stdio stream reading functions. Filenames are WF>>handed out to PHP and opened up using the streams layer. WF>> WF>>The rule for the fixup function is that it either errors out, or sets WF>>up the zend_file_handle so that zend_stream_XXX functions will work. But this means if you get a file handle which is ZEND_HANDLE_STREAM, you cannot use it as a stream - it might be result of stream open, in which case handle is php_stream *, or result of fixup, in which case is't FILE *. Don't you think it's wrong?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Wez Furlong

21 years ago
What are you trying to do exactly? The engine only needs to read from such a file handle and feed that data into its lexer and parser. --Wez. On Wed, 9 Mar 2005 17:22:58 +0200 (IST), Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

21 years ago
WF>>What are you trying to do exactly? For example, I try to stat a file_handle (in case it's possible - i.e. either it's a file or stream operator allows doing stat on it). Current way of doing things guarantees crash on STREAM handle whatever I do, since there's no way to know is this STREAM a FILE * (and thus one should fstat) or php_stream * (and thus one should use stream ops). It wasn't like this before. WF>>The engine only needs to read from such a file handle and feed that WF>>data into its lexer and parser. Depends on what do you mean by "the engine". Are you claiming that there is not and should not be any way to do anything but reading and closing the file_handle? It certainly wasn't so before the fixup appeared.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Wez Furlong

21 years ago
Why do you need to stat it? You can't rely on stat working. --Wez. On Wed, 9 Mar 2005 17:47:13 +0200 (IST), Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

21 years ago
WF>>You can't rely on stat working. Why not? What's so special in stat that it can not work on file handle? And why this STREAM type at all - if the only places it is used is where you have switch on type anyway or in zend_stream.c where you could have the switch as well? What did you achive by this but breaking all code that used file_handle for more that read/close? So far I see that by using fixup and converting all FPs to STREAMs you saved one if in zend_stream_read/zend_stream_getc and that's it. Is there anything I miss?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Wez Furlong

21 years ago
Yes, you missed that a stream can be any stream from PHP land. Which code in the engine does more than read/close? --Wez. On Wed, 9 Mar 2005 18:00:11 +0200 (IST), Stanislav Malyshev <stas@zend.com> wrote:

Stanislav Malyshev

21 years ago
WF>>Yes, you missed that a stream can be any stream from PHP land. If it's the PHP stream that's ok for it to be STREAM. PHP streams have own operators for foing things, so if I know STREAM type refers to PHP stream it is completely OK. What I do not understand is why you convert FP to STREAM. Only value from this conversion I can see is that zend_stream_read/zend_stream_getc now call reader instead of doing if and then calling either reader for stream or file-reading function of the engine (which, btw, is private to the engine so you even can not call or set it from outside - meaning it could be as well inlined directly in zend_stream_read/zend_stream_getc - and these seem to be the only functions that use the reader anyway). WF>>Which code in the engine does more than read/close? My code. Since handlers using file_handle (e.g. compile_file handler) is overridable, any code can be in these handlers. And what I want is some sane rules about what can be in file_handle. Limiting file_handle to read/close only doesn't seem reasonable to me, especially that it wasn't so for a long time and only reason so far I see for it is saving two ifs - and underlying file protocols (either fd or FILE * or PHP stream) allow much more than just reading and closing.
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115

Wez Furlong

21 years ago
Bitching about code breakage for something that is not in public CVS isn't going to win you any points. This code was added specifically so that include and require will operate correctly on all php streams. Not only that, but it has been there for quite a long time now; you've had plenty of time to raise issues. If you need to call stat from within the engine, it can be added, but you need to be aware that stat will not work in all cases, and the fact that no other place in the engine needed it at the time it was written explains why there is no stat prototype. The purpose of the stream structure is not to save ifs, it's to allow the engine to call into the php streams layer without a hard dependency on PHP, which is something you guys have been touchy about in the past. --Wez. On Wed, 9 Mar 2005 18:22:45 +0200 (IST), Stanislav Malyshev <stas@zend.com> wrote:

Zeev Suraski

21 years ago
At 18:14 09/03/2005, Wez Furlong wrote:
>Yes, you missed that a stream can be any stream from PHP land. > >Which code in the engine does more than read/close?
Wez, I think it's beyond looking into which code in the engine does more than read/close right now. It has to do with having infrastructure code that makes sense and can be relied upon - whether you build other engine code on top of that, or other extensions, close or open. And right now it appears our APIs are slightly broken, since by looking at the file handle type, you can no longer determine what you can do with it. Can you explain what kind of things the promotion from a simple FP to a stream enables us to do? Zeev

Marcus Boerger

21 years ago
Hello Zeev, Thursday, March 10, 2005, 3:12:36 PM, you wrote:
> At 18:14 09/03/2005, Wez Furlong wrote: >>Yes, you missed that a stream can be any stream from PHP land. >> >>Which code in the engine does more than read/close?
> Wez,
> I think it's beyond looking into which code in the engine does more than > read/close right now. It has to do with having infrastructure code that > makes sense and can be relied upon - whether you build other engine code on > top of that, or other extensions, close or open. And right now it appears > our APIs are slightly broken, since by looking at the file handle type, you > can no longer determine what you can do with it.
> Can you explain what kind of things the promotion from a simple FP to a > stream enables us to do?
For a short idea, we could implement something like jar's possible named par as in php archive :-)
-- Best regards, Marcus mailto:mail@marcus-boerger.de

Stanislav Malyshev

21 years ago
MB>>For a short idea, we could implement something like jar's possible MB>>named par as in php archive :-) What I don't understand is how this is connected to promoting FP to STREAM. Won't it be implemented via PHP streams anyway?
-- Stanislav Malyshev, Zend Products Engineer stas@zend.com http://www.zend.com/ +972-3-6139665 ext.115