Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:64179
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.44 as permitted sender)
Message-ID: <50C0841E.6000507@gmail.com>
Date: Thu, 06 Dec 2012 12:40:14 +0100
User-Agent: Thunderbird
MIME-Version: 1.0
To: Pierre Joye <pierre.php@gmail.com>
CC: PHP internals <internals@lists.php.net>
References: <CAEZPtU6fQCx+JdehkBL=DowTRn+qC4RqzkHPgX6-uZUuQPQOuA@mail.gmail.com>
In-Reply-To: <CAEZPtU6fQCx+JdehkBL=DowTRn+qC4RqzkHPgX6-uZUuQPQOuA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Passing process handles to proc_open and co
From: keisial@gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)

On 06/12/12 09:49, Pierre Joye wrote:
> hi!
>
> While looking at the bug #63073, I was wondering if we could simply do
> not pass open handles to the newly created child process.

Looking at proc_open, where there is an explicit CreateProcess (we seem
to be using the library popen for the exec()...)

If $pipes is empty and $descriptorspec doesn't require more than 0,1,2
then it should be safe not to set bInheritHandles.

However, in other cases inheriting handles *will* be needed.


> The main issue in this bug is the session related handles. They are
> passed to the parent process, which hangs until their are closed. It
> indeed  does not happen (usually) until the end of the request. It
> makes these functions almost unusable as soon as sessions are used.
>
> These functions are about calling external commands and I fail to see
> which usage may require to access PHP related handles. Does anyone see
> any issue by not passing them anymore? And fixing this bug (and a
> couple of other I think)?
>
> It is windows only. Not sure if we do the same on other platforms.
The issue was only detected with session files. Windows is probably the
only mainstream OS without F_SETFD. When it's available, mod_files.c
will set the FD_CLOEXEC, which should remove the issue from the session.

The same issue could still arise from other files, though. For instance
bug 44994 reported that it was happening with error.log.


I don't know *why* session files are an issue. It would make sense if they
were pipes and the reading was missed with the inherited child unkowingly
holding a write descriptor, but these are plain files.
Maybe related to the fact that they are locked, if the locks are also
inherited,
plus the way Windows may delay its automatic UnlockFile() after the process
closes.