Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29774
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 204.11.219.139 cause and error)
Message-ID: <465756D4.1080604@lerdorf.com>
Date: Fri, 25 May 2007 14:36:20 -0700
User-Agent: Thunderbird 2.0.0.0 (Macintosh/20070326)
MIME-Version: 1.0
To: Uwe Schindler <thetaphi@php.net>
CC: "'Stanislav Malyshev'" <stas@zend.com>,
        "'PHP Internals'" <internals@lists.php.net>
References: <4657170E.8060701@zend.com> <46571CCC.4030801@zend.com> <46573710.6070800@lerdorf.com> <46573903.2060204@zend.com> <000001c79f12$9b6650b0$0201a8c0@VEGA>
In-Reply-To: <000001c79f12$9b6650b0$0201a8c0@VEGA>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] TSRM changes broke windows compile
From: rasmus@lerdorf.com (Rasmus Lerdorf)

Uwe Schindler wrote:
>>> An extra syscall on every file open isn't exactly miniscule.
>> It's a syscall not related to any filesystem or I/O so it can't be that
>> bad. And we managed to live with it so far.
>>
>>> Edin also just built Windows binaries without problems.  Why did it work
>>> for him?
>> I have no idea. But it is obvious that it doesn't work in all
>> environments, and it worked before just fine. Anyway, both breaking
>> build _and_ intoducing dependency of TSRM on PHP and both in a minor
>> version _and_ both without discussing it doesn't look like very good
>> idea to me. I would propose:
>> 1. Revert it for 5.2.3
>> 2. Discuss if we want TSRM/Zend be now usable only with PHP
>> 3. Discuss if we really need this patch and if so can we do it without
>> breaking (2)
> 
> As I was involved today this morning also with startup failures because of
> this change, I came to the following:
> 
> It would be perhaps OK to make TSRM dependent on some global PHP functions,
> but to make it depend on SAPI code that is only for webserver interaction
> (!) and not related to TSRM (yes SAPI uses TSRM but not the other way round)
> is not so good. And that only because of a not IO-related syscall!

It may not be IO, but on some systems fetching the time is actually
quite expensive.  And SAPI isn't only for web server interaction.  SAPI
is a general-purpose abstraction API that sits between PHP and anything
PHP talks to.  CGI, CLI, and even embedded PHP are all SAPI-driven.
There is no way to use PHP without at least a stub SAPI layer.

> A solution would be to make a function pointer inside TSRM that normally
> maps to time() or a TSRM-local wrapper of it. This would make TSRM not
> dependent on PHP. On the PHP part in SAPI startup there could optionally be
> a redirect of the pointer to SAPI's get_request_time() implementation.

That could be done, yes.  I'm just not sure it is worth the complexity.
 TSRM is obviously a PHP-specific thing and it is already somewhat
SAPI-dependant even without this.  The THREAD_T and MUTEX_T definitions
change based on the chosen SAPI.  It doesn't explicitly include SAPI.h
because it relies on the side-effect of TSRM.h being included after the
SAPI stuff.  I don't see an explicit include as really changing things
very much.

-Rasmus