Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52136
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.170 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
        b=lBM2SLuwMdxfy03Bg345724W41+ZuTYA7SNQ5gUuwuxJjQfiip+aAhTP7fMGk0P1dx
         Z8DVOh65S4pC3X2tluT3jH/9HpiAi4R3AaGiFv74DZFHU2ZsLOnnGa+ulFMVXqXueJ27
         LX7UjT9PpkQCAwcqR7eNtMEeqKhmWx30VKuIY=
MIME-Version: 1.0
Sender: tyra3l@gmail.com
In-Reply-To: <op.vu44tcu3idpuyk@cataphract-old.dulce.lo.geleia.net>
References: <BANLkTimbSibmdXx_MSNqpUX2Xyke17K94A@mail.gmail.com>
	<op.vuq599voidpuyk@cataphract>
	<BANLkTiks16OT1acO1M2D61o5kybYy-B1Qg@mail.gmail.com>
	<BANLkTik1Os+3HJUoKK0JV0RgjZE=V4s-dQ@mail.gmail.com>
	<BANLkTimYxGaTvn=wy2OdQ6t39SMtjK6fmA@mail.gmail.com>
	<BANLkTinrStuv55X4SH3HTCByzs+VjjnDRg@mail.gmail.com>
	<op.vu44tcu3idpuyk@cataphract-old.dulce.lo.geleia.net>
Date: Sun, 8 May 2011 11:23:59 +0200
Message-ID: <BANLkTim3noE655Zz=s9hehk8KXO8qPHoiQ@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=0016e657b06a68d6e104a2c048cd
Subject: Re: [PHP-DEV] adding low level file handling stuff
From: info@tyrael.hu (Ferenc Kovacs)

--0016e657b06a68d6e104a2c048cd
Content-Type: text/plain; charset=UTF-8

>
> adding dup2 support for the php://fd stream would be better than the
>>>>> current situation, but I can't see why are we trying to force
>>>>> everything into that.
>>>>> I mean everything on the http://www.php.net/manual/en/wrappers.php can
>>>>> be
>>>>> achived through a function also.
>>>>> there are some case when you can save a couple of lines of code with
>>>>> the wrappers and with http://www.php.net/manual/en/context.http.phpbut there is no method for opening FDs or the dup2 that you mentioned.
>>>>> I think that it would be more consistent with the rest of the language,
>>>>> and one would more likely to find fdopen than fopen('php://fd/1'); in the
>>>>> documentation.
>>>>>
>>>>
> I just don't see the point of duplicating functionality, especially when
> there's already a closely related wrapper.
>
> It's not true that everything in http://php.net/wrappers can can be done
> in another fashion. In fact, for the php:// wrappers, which is what we're
> talking about, ONLY ONE (php://filter) duplicates functionality that can be
> achieved with functions.
>
>
you are right, not everything, but many of them is either have alternative
in core, or had it through pecl when that stream was introduced AFAIK .


>
>  closing the stdout without reopening also caused problems for me in case
>>>>> of an error happens, but this shouldn't happen if you properly reopen it, so
>>>>> I would be interested what exactly happened there.
>>>>>
>>>>
> Yes, this causes a memory leak. Maybe that was the problem I found. Duping
> the file descriptor after the call to dup2 would solve this, which I think
> is one more reason not to expose these low-level functions directly and
> provide a safer alternative (more below).
>

this is why I think that it would be better to provide a way to
redirect/reopen the STDIN/STDOUT/STDERR. currently one can only close them,
which could cause problmes, if something directly or indirectly tries to use
one of those fps.


>
>
>>>> I put together the fileno, fdopen, dup2, fclose stuff as a pecl
>>>> extension(called fildes), the sourcecode available here:
>>>> https://github.com/Tyrael/php-fildes
>>>> [...]
>>>>
>>> Could somebody review the source? as I mentioned in my previous email
>>> I had some problem here:
>>> https://github.com/Tyrael/php-fildes/blob/master/fildes.c#L211
>>>
>>> if I define the second argument as int, the first argument will be always
>>> 0.
>>> I have no idea whats going there.
>>>
>>>
> See http://lxr.php.net/xref/PHP_TRUNK/README.PARAMETER_PARSING_API#72
>
>
okay, I read that before, but somehow I belived that I should use ints
because the C functions use its for fds.
I will update that.


>
>  and I forgot to ask the most important thing:
>> what do you think about the feature itself?
>> I would really like to have it in the core, but I think it would be
>> better to have this as functions, than adding more stream magic.
>> I'm not sure where would this functions fit the best.
>> 1, it could be added to the filesystem functions (we already have some
>> which are only supported on some systems)
>> 2, it could be added to the posix functions (would be logical)
>> 3, it could be added as stream stuff (Gustavo supports this imo)
>> 4, it could be added to the dio pecl extension (could fit in there,
>> but it's not in the core, and the package doesn't seem much alive)
>> 5, it could be added to pecl as a different extension (bad idea, imo)
>>
>>
> PHP tries to abstract away these kind of details; I don't think direct
> access to low level I/O functions is appropriate in the core. The dio pecl
> extension would seem more appropriate. I don't know how alive it is, but if
> I recall correctly, it got a new maintainer last year.
>
> The POSIX extension would also seem to make sense, but it seems more
> focused on another class of functions and is not available on Windows.
>
> That said, if some useful use case is not available (or is available, but
> it's awkward) in PHP, we should try to fix it. If I understand correctly,
> what compels you is being able to replace stdin, stdout and stderr.
> I would tend to support #3; for reference here goes the change to php://fd
> that would be necessary. The problem is, as far as I know, there's no way to
> retrieve the file descriptor associated a stream, so we'd still have to rely
> on opening order.
>
> One possible solution would be to add this information to the wrapper data
> of the "plain files" and in systems other than Windows, to other relevant
> stream types (e.g. sockets). I think your solution of calling stream_cast is
> a good option because in Windows the socket streams return socket handles --
> file descriptors are an abstraction in the C lib, not really part of the
> windows API -- and because in some stream implementations that call has
> important side effects.
>
> Another option would option would be to unburden the user from dealing with
> file descriptors completely and provide a function to replace the standard
> file descriptors with a stream.
>

I agree, I think that the best solution would be to
- add support for replacing a stream with another (a similar function for
http://php.net/manual/en/function.stream-copy-to-stream.php<http://hu2.php.net/manual/en/function.stream-copy-to-stream.php>
or
maybe extending that), which would be available on all platforms, this would
cover my initial use-case.
- I think we should also provide the fileno functionality, because without
that, the php://fd is pretty useless.
- anything else, like dup2, fcntl should go to the dio or posix extension,
that would be useful for some people.

what do you think?

Tyrael

--0016e657b06a68d6e104a2c048cd--