Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:43831
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.220 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:reply-to:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=hRmcRcbGmMe5cIOThRAG8vOxc3JiXEzGzzwyUzkk78boq46f9QpgDrktYB2h/rbnY7
         JChq+mrXNt0kUArbT6Jy0oDh/yvl7fn114MmQIw84emNEZTy0hEGnX/vVRTmWIUuafjU
         PXSPT6Fh+hm4eqaQfDBctkDEmsEOxeYnOsvZI=
MIME-Version: 1.0
Sender: arnaud.lb@gmail.com
Reply-To: lbarnaud@php.net
In-Reply-To: <49FE9AE7.4000008@php.net>
References: <6604D94D40FD465F992144110B075BB5@pc1>
	 <E17F0EFAC0F847C994EBDA6D020E52BF@PC3EE1F19287>
	 <9D5D4CBF-5CB1-47EC-81F4-59E3C48EEEEF@pooteeweet.org>
	 <C8E7CB69316B42D1B8BB5ED78408088D@PC3EE1F19287>
	 <B06CC8E0A66F4959B3BFC4AA0698223D@pc1> <49FE9AE7.4000008@php.net>
Date: Mon, 4 May 2009 13:40:46 +0200
Message-ID: <b6f28ec20905040440w2cfaf934qfa001e3689c566b7@mail.gmail.com>
To: shire@php.net
Cc: Matt Wilmas <php_lists@realplain.com>, internals@lists.php.net, 
	Nuno Lopes <nlopess@php.net>, Lukas Kahwe Smith <mls@pooteeweet.org>, Dmitry Stogov <dmitry@zend.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [PATCH] Scanner "diet" with fixes, etc.
From: lbarnaud@php.net (Arnaud Le Blanc)

Hi,
On Mon, May 4, 2009 at 9:36 AM, shire <shire@php.net> wrote:
> Regarding the ZEND_MMAP_AHEAD issue and the temp. fix that Dmitry put in =
we
> need to find a solution to that, perhaps I can play with that this week t=
oo
> as I think I'm seeing some related issues in my testing of 5.3. =C2=A0Ess=
entially
> we abuse ZEND_MMAP_AHEAD by adding it to the file size and passing it to =
the
> mmap call which isn't at all valid and only really works up to PAGESIZE. =
=C2=A0We
> could possibly use YYFILL to re-allocate more space as necessary past the
> end of file to fix this.

I was thinking of doing something like that with YYFILL too. However
there is a bunch of pointers to take in to account and to update (e.g.
yy_marker, yy_text, etc).

There is mmap(MAP_FIXED) as an other temporary solution. The idea is
to map the entire file rounded up to a whole page size, and to map the
last (already mapped) page to anonymous memory using MAP_FIXED. In the
end we get a readable contiguous memory region with the file data and
ZEND_MMAP_AHEAD.
This should work on many systems as long as the requested address is
already part of the process's address space (which is always the case
here). When this fails we can fallback to malloc/read.

Regards,

Arnaud