Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91981
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CA+kxMuQM1VCpeue0ZMV9KmW0f7PSOeWd2EE7r7m+gt=CHa5_FQ@mail.gmail.com>
References: <CAAoDVDA=edahzD_aH7gCcQzrDX0ZzqDoqn4u3PPFvUX9eQG8yw@mail.gmail.com>
 <CA+kxMuQM1VCpeue0ZMV9KmW0f7PSOeWd2EE7r7m+gt=CHa5_FQ@mail.gmail.com>
Date: Mon, 28 Mar 2016 19:03:09 -0500
Message-ID: <CAAoDVDAq5L-Ew_HH-syQuf22rZ_20f=rNyqCJ8_K2eQwogZ9wA@mail.gmail.com>
To: Dan Ackroyd <danack@basereality.com>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Handling "Bad file descriptor" during stream_select()
From: grzegorz129@gmail.com (Grzegorz Zdanowski)

2016-03-28 11:19 GMT-05:00 Dan Ackroyd <danack@basereality.com>:
> On 28 March 2016 at 02:57, Grzegorz Zdanowski <grzegorz129@gmail.com> wro=
te:
>>  by =E2=80=9Egone away=E2=80=9C
>> I mean some underlying error like forceful close of FD and not a
>> standard disconnection
>> of the client.
>
> What problem exactly are you trying to solve, and do you have a way of
> showing the problem that isn't just what looks like a programming
> mistake?

You're missing one point - the native file descriptor living inside a
kernel and somewhat
managed by PHP C code can change it's state independently from PHP knowledg=
e.
The problem is stream resource is only an loosely representation of
native FD, not an
actual file descriptor.
TBH I don't know any way to damage the actual FD by programmer mistake in P=
HP.

I came across the problem in real environment in two cases:
1. Socket was listening with some specific IP and network card gone
away. Every call
to stream_select() produced situation described in OP and send the
code into dead-loop.
2. Using hardware-dependent socket (like ttys to USB<>RS232 converters) you=
 can
trigger such error by simply disconnecting the USB cord (not always,
because some
drivers will just trigger EOF on socket and close it gracefully).

> e.g. The following code works fine. The file being closed doesn't
> affect the filehandle
>
> $fileHandle =3D fopen('foo.txt', 'r+');
> unlink('foo.txt');
> $data =3D fread($fileHandle, 20);
It's perfectly understandable - files have nothing to do with file
descriptors opened for
them.

> The following code doesn't work fine. The filehandle being closed,
> surprisingly enough, makes it not usable any more:
>
> $fileHandle =3D fopen('foo.txt', 'r+');
> fclose($fileHandle);
> $data =3D fread($fileHandle, 20);
Yes, that's true - after you call fclose() PHP gracefully closes the
socket and marks
the memory, so $fileHandle will no longer be a valid stream resource.


> So I don't understand what problem you're trying to analyze, other
> than closed file descriptors are closed.
If the socket was properly closed there's no discussion - you deal
with thousand times
a day, but the problem comes when the underlying FD will gone away.

Actually I found in C you can just call fcntl(FD, F_GETFD) and you'll
get -1 if given FD is
no longer valid FD. In PHP there's no way to do it - that's my problem.


---
Greg 'aka kiler129