Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:29779
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: <46576108.6070300@lerdorf.com>
Date: Fri, 25 May 2007 15:19:52 -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> <465756D4.1080604@lerdorf.com> <000001c79f19$05a337d0$0201a8c0@VEGA>
In-Reply-To: <000001c79f19$05a337d0$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:
>>> 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.

That's simply not the case.  Look at the nsapi code:

#define NSAPI 1

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include "php.h"
#include "php_variables.h"
#include "ext/standard/info.h"
#include "php_ini.h"
#include "php_globals.h"
#include "SAPI.h"
#include "php_main.h"
#include "php_version.h"
#include "TSRM.h"
#include "ext/standard/php_standard.h"
#include <sys/types.h>
#include <sys/stat.h>

It defines NSAPI before including TSRM.h and in TSRM.h we have:

#elif defined(NSAPI)
# define THREAD_T SYS_THREAD
# define MUTEX_T CRITICAL

So I don't see how this is no longer the case.

-Rasmus