Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29777
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: "'Rasmus Lerdorf'" <rasmus@lerdorf.com>
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> <465756D4.1080604@lerdorf.com>
Date: Sat, 26 May 2007 00:07:01 +0200
Message-ID: <000001c79f19$05a337d0$0201a8c0@VEGA>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-Reply-To: <465756D4.1080604@lerdorf.com>
Thread-Index: AcefFNxy6pkVcZ0KRn2zPoVdrKNK5gAAmQeA
Subject: RE: [PHP-DEV] TSRM changes broke windows compile
From: thetaphi@php.net ("Uwe Schindler")

> > 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.

I know, I wanted only to put more pressure on that.

> > 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. 

This is no longer the case. E.g. when compiling the module for the NSAPI
webserver (Sun Java System Webserver) there should be a global define like
-DNSAPI in the makefiles (not only for nsapi.c) which is not. Because of
that all SAPIs do not have an effect on the thread implementation. When
compiling PHP with ZTS you always get an .o file that links to pthreads.
This must be the case, because without that it would not be possible to link
a CLI PHP in parallel to the webserver specific SAPI.

Because of that limitation for example the Sun Webservers on (SJSWS) on AIX
crash on startup (there are a lot of bug reports about that, but I cannot
help because I have no access to such a system). I only know that SJSWS is
implemented on AIX not with POSIX threads. And on Solaris the webservers
also crash when you switch to an alternative "kernel" (do not know the exact
name) thread implementation in the webserver. This is because the ifdefs in
TSRM.h never apply specific to the SAPI implementation.

> 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.

It was just a suggestion. But it should not hard to implement.

Uwe