Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29773
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain php.net from 80.190.230.99 cause and error)
To: "'Stanislav Malyshev'" <stas@zend.com>,
	"'Rasmus Lerdorf'" <rasmus@lerdorf.com>
Cc: "'PHP Internals'" <internals@lists.php.net>
References: <4657170E.8060701@zend.com> <46571CCC.4030801@zend.com> <46573710.6070800@lerdorf.com> <46573903.2060204@zend.com>
Date: Fri, 25 May 2007 23:21:05 +0200
Message-ID: <000001c79f12$9b6650b0$0201a8c0@VEGA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcefAxpmpL/jj0StSuGVEwzIlKSt/wADfL2A
In-Reply-To: <46573903.2060204@zend.com>
Subject: RE: [PHP-DEV] TSRM changes broke windows compile
From: thetaphi@php.net ("Uwe Schindler")

> > 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!

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.

Uwe