Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Good luck trying to retrain millions of programmers to use a CGI object or a function to retrieve GPC values. Really, how much of a performance hit is Sara's patch going to be, compared to other things in PHP 6? -Andrei On Jan 26, 2007, at 3:38 PM, Pierre wrote: That's somehow my thoughts too. My initial proposal was to have a simple JIT for GPC at runtime (which is not that hard to implement but not easy either ;) and then use filter (as it exists for this exact purpose!). Another approach I really like is the cgi object, see perl or python for nice implementations examples. --Pierre ps: we are running in circle, I said that already many times already... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
On 1/27/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: Hi Sara, > -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 8:11 PM > To: Dmitry Stogov > Cc: internals@lists.php.net; 'Andi Gutmans'; 'Andrei > Zmievski'; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > > I fixed one error in your patch, so now it passes all tests. > > > Which error? I notice some changes related to minimizing performance > impact, but I'm not seeing what I did wrong. Just curious for my own > benefit on that one. During combination of ZEND_FETCH, ZEND_FETCH_OBJ into one ZEND_FETCH_OBJ with IS_CV you didn't check for first check type. So you could combine fetch of static (or global) variable into CV. You can just run "make test" with your and my patch and see difference. > > BTW I am against this patch. > > > Fair enough. > > > 1) It adds sloppily built functionality into the core > Well, you sure know how to sweet-talk a gal. My English isn't good and I spent some time with dictionary to write that I think :) Really, I think that you use the most complicated way to solve HTTP input encoding problem. May be we no longer need for autoglobals at all and can use simple functions like http_get_var($name). That's somehow my thoughts too. My initial proposal was to have a simple JIT for GPC at runtime (which is not that hard to implement but not easy either ;) and then use filter (as it exists for this exact purpose!). Another approach I really like is the cgi object, see perl or python for nice implementations examples. --Pierre ps: we are running in circle, I said that already many times already... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Sara, > -Original Message- > From: Sara Golemon [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 8:11 PM > To: Dmitry Stogov > Cc: internals@lists.php.net; 'Andi Gutmans'; 'Andrei > Zmievski'; Zeev Suraski; Stanislav Malyshev > Subject: Re: [PHP-DEV] Runtime-JIT, the whole enchilada > > > > I fixed one error in your patch, so now it passes all tests. > > > Which error? I notice some changes related to minimizing performance > impact, but I'm not seeing what I did wrong. Just curious for my own > benefit on that one. During combination of ZEND_FETCH, ZEND_FETCH_OBJ into one ZEND_FETCH_OBJ with IS_CV you didn't check for first check type. So you could combine fetch of static (or global) variable into CV. You can just run "make test" with your and my patch and see difference. > > BTW I am against this patch. > > > Fair enough. > > > 1) It adds sloppily built functionality into the core > Well, you sure know how to sweet-talk a gal. My English isn't good and I spent some time with dictionary to write that I think :) Really, I think that you use the most complicated way to solve HTTP input encoding problem. May be we no longer need for autoglobals at all and can use simple functions like http_get_var($name). Thanks. Dmitry. > and slowdowns EACH > > dimension or property fetch both at run-time and > compilation-time. I think > > it is a big cost for $_GET/$_POST encoding-conversion, but > it is only my > > opinion. > > > For disarmed callbacks, it amounts to a vector lookup and a couple > integer compares, I'd hardly call that a "big cost". As to armed > callbacks, well, if they're still armed then they still have > some work > to do. Refer to prior posts in the thread as to why this work would > (and should) be deferred. > > > 2) It adds pointer to zend_auto_global into > zend_compiled_variable. This > > makes troubles for opcode caches - > zend_compiled_variable(s) may lay in > > shared memory, so they cannot point to process specific > data. I think this > > issue can be fixed using indirect pointer (index). > > > Excellent point. That will need to be addressed > > > Why did you reject auto-globals as overloaded arrays? > > > See earlier posts in this thread, such as the one I sent you > less than a > week ago and to which you replied indicating you understood it. > > If you thinking breaking BC is preferable to this "sloppy" approach, > then we can reexamine that. If you have a better, third > approach, which > solves all of the issues already outlined, then I'd love to hear it. > > -Sara > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP6 - x64 SegFault
Yeah. The earlier we get reports the better. Andi > -Original Message- > From: Andrei Zmievski [mailto:[EMAIL PROTECTED] > Sent: Friday, January 26, 2007 9:41 AM > To: Antony Dovgal > Cc: Chris Malton; internals@lists.php.net > Subject: Re: [PHP-DEV] PHP6 - x64 SegFault > > On Jan 26, 2007, at 12:58 AM, Antony Dovgal wrote: > > > On 01/26/2007 10:27 AM, Chris Malton wrote: > >> Hi, > >>I'm new to the newsgroup and I'm trying to debug PHP 6 > on a test > >> server > >> (x64 architecture). > > > > Why do you do that? I mean, PHP6 is not even an alpha and it's too > > early to test it unless you're a developer. > > What's wrong with him trying to test it out? Let's not be so > exclusive here. > > -A > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 - x64 SegFault
On Jan 26, 2007, at 12:58 AM, Antony Dovgal wrote: On 01/26/2007 10:27 AM, Chris Malton wrote: Hi, I'm new to the newsgroup and I'm trying to debug PHP 6 on a test server (x64 architecture). Why do you do that? I mean, PHP6 is not even an alpha and it's too early to test it unless you're a developer. What's wrong with him trying to test it out? Let's not be so exclusive here. -A -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
I fixed one error in your patch, so now it passes all tests. Which error? I notice some changes related to minimizing performance impact, but I'm not seeing what I did wrong. Just curious for my own benefit on that one. BTW I am against this patch. Fair enough. 1) It adds sloppily built functionality into the core Well, you sure know how to sweet-talk a gal. and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. For disarmed callbacks, it amounts to a vector lookup and a couple integer compares, I'd hardly call that a "big cost". As to armed callbacks, well, if they're still armed then they still have some work to do. Refer to prior posts in the thread as to why this work would (and should) be deferred. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). Excellent point. That will need to be addressed Why did you reject auto-globals as overloaded arrays? See earlier posts in this thread, such as the one I sent you less than a week ago and to which you replied indicating you understood it. If you thinking breaking BC is preferable to this "sloppy" approach, then we can reexamine that. If you have a better, third approach, which solves all of the issues already outlined, then I'd love to hear it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
I fixed one error in your patch, so now it passes all tests. Which error? I notice some changes related to minimizing performance impact, but I'm not seeing what I did wrong. Just curious for my own benefit on that one. BTW I am against this patch. Fair enough. 1) It adds sloppily built functionality into the core Well, you sure know how to sweet-talk a gal. and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. For disarmed callbacks, it amounts to a vector lookup and a couple integer compares, I'd hardly call that a "big cost". As to armed callbacks, well, if they're still armed then they still have some work to do. Refer to prior posts in the thread as to why this work would (and should) be deferred. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). Excellent point. That will need to be addressed Why did you reject auto-globals as overloaded arrays? See earlier posts in this thread, such as the one I sent you less than a week ago and to which you replied indicating you understood it. If you thinking breaking BC is preferable to this "sloppy" approach, then we can reexamine that. If you have a better, third approach, which solves all of the issues already outlined, then I'd love to hear it. -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] COM extension defects: Patch for defect 37927
Hi Internals, Attached are details of a suggested patch for COM extension defect 37927 (http://bugs.php.net/bug.php?id=37927). All comments welcome; good or bad. Regards Andy Andy Wharmby IBM United Kingdom Limited Winchester, England SO21 2JN E-mail: [EMAIL PROTECTED] _*COM Defect 37927*_ This defect actually reports issues with 2 different event sink interfaces, DwebBrowserEvents2 and DWebbrowserEvents. So taking each one in turn: *DWebBrowserEvents2::NewWindow2 Event * This event is documented at : http://msdn.microsoft.com/workshop/browser/webbrowser/reference/ifaces/dwebbrowserevents2/newwindow2.asp The defect details an issue with the NewWindow2 event handler but my testing has shown the exact same issue with NewWindows3 event too. The problem here is that the user defined event handler is not getting called when the associated event occurs in IE and my investigations have shown this is due to a bug in the COM extension code. Examining the COM trace output with DebugView shows: [4716] T=1890 [4716] PHP:IEEventSinker InvokeEx [4716] T=1890 [4716] -- Invoke: 251 newwindow2 [10] flags=0001 args=2 [4716] T=1890 [4716] alloc zval for arg 0 VT=4009 << only one of two arguemets gets processed !! [4716] T=1890 [4716] PHP:IEEventSinker InvokeEx
Re: [PHP-DEV] PHP 5.2.1RC4 Released
On 01/26/2007 05:39 PM, Uwe Schindler wrote:
Installed RC4 short time ago, works great. I found only a problem in
phpinfo():
Registered PHP Streams: zip
Registered Stream Socket Transports: tcp
Registered Stream Filters: string.rot13
It only displays the FIRST registered PHP stream. Testing with
fopen("http://...";) works, so all streams are available. This bug was also
in RC3 but I thought it was related to http://bugs.php.net/bug.php?id=40168
and did not start any separate bug report.
Fixed, thanks.
It was my fault, sorry.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.2.1RC4 Released
I can confirm this on Fedora with gcc 4.1.1, pretty sure its a
regression based on bug #40168
Scott
Uwe Schindler wrote:
Installed RC4 short time ago, works great. I found only a problem in
phpinfo():
Registered PHP Streams: zip
Registered Stream Socket Transports: tcp
Registered Stream Filters: string.rot13
It only displays the FIRST registered PHP stream. Testing with
fopen("http://...";) works, so all streams are available. This bug was also
in RC3 but I thought it was related to http://bugs.php.net/bug.php?id=40168
and did not start any separate bug report.
System is Solaris 9 SPARC, GCC 3.3
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
-Original Message-
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
Sent: Friday, January 26, 2007 1:33 AM
To: internals@lists.php.net List
Subject: [PHP-DEV] PHP 5.2.1RC4 Released
The final release candidate for PHP 5.2.1, RC4 is now available for
download. Pending any problems this will be released as 5.2.1 next
week, so this is the last chance to identify any critical issues
before it is too late. If you have not tried any previous RCs, please
do so now. The tar balls can be found at the URLs below and win32
binaries will follow shortly.
http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum:
f50578276f653b1f523150e3ff987f03)
http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum:
361197eb2b21b36e2e20cb132da2cf16)
I'd like to ask all developers to refrain from making any (no matter
how trivial) commits to the 5.2 branch until 5.2.1 is released, if
you feel you have a critical patch, please run it by me first, thanks.
Ilia Alshanetsky
5.2 Release Master
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.2.1RC4 Released
Installed RC4 short time ago, works great. I found only a problem in
phpinfo():
Registered PHP Streams: zip
Registered Stream Socket Transports: tcp
Registered Stream Filters: string.rot13
It only displays the FIRST registered PHP stream. Testing with
fopen("http://...";) works, so all streams are available. This bug was also
in RC3 but I thought it was related to http://bugs.php.net/bug.php?id=40168
and did not start any separate bug report.
System is Solaris 9 SPARC, GCC 3.3
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Bremen, Germany
> -Original Message-
> From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 26, 2007 1:33 AM
> To: internals@lists.php.net List
> Subject: [PHP-DEV] PHP 5.2.1RC4 Released
>
> The final release candidate for PHP 5.2.1, RC4 is now available for
> download. Pending any problems this will be released as 5.2.1 next
> week, so this is the last chance to identify any critical issues
> before it is too late. If you have not tried any previous RCs, please
> do so now. The tar balls can be found at the URLs below and win32
> binaries will follow shortly.
>
> http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum:
> f50578276f653b1f523150e3ff987f03)
> http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum:
> 361197eb2b21b36e2e20cb132da2cf16)
>
> I'd like to ask all developers to refrain from making any (no matter
> how trivial) commits to the 5.2 branch until 5.2.1 is released, if
> you feel you have a critical patch, please run it by me first, thanks.
>
> Ilia Alshanetsky
> 5.2 Release Master
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Dmitry, On 1/26/07, Dmitry Stogov <[EMAIL PROTECTED]> wrote: Hi Sara, I fixed one error in your patch, so now it passes all tests. BTW I am against this patch. 1) It adds sloppily built functionality into the core and slowdowns EACH dimension or property fetch both at run-time and compilation-time. I think it is a big cost for $_GET/$_POST encoding-conversion, but it is only my opinion. 2) It adds pointer to zend_auto_global into zend_compiled_variable. This makes troubles for opcode caches - zend_compiled_variable(s) may lay in shared memory, so they cannot point to process specific data. I think this issue can be fixed using indirect pointer (index). I would prefer rollback "auto-globals CV" patch and commit (or not) the whole patch after conclusion. Why did you reject auto-globals as overloaded arrays? As I already told you in my initial proposal (which is simpler than this solution), they do not work in all cases (check the various bugs about them) and they will bring a huge breakage as is_array($objarray) returns false. The later is certainly fixable (with slowness too), I'm not sure about the other issues. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Runtime-JIT, the whole enchilada
Hi Sara,
I fixed one error in your patch, so now it passes all tests.
BTW I am against this patch.
1) It adds sloppily built functionality into the core and slowdowns EACH
dimension or property fetch both at run-time and compilation-time. I think
it is a big cost for $_GET/$_POST encoding-conversion, but it is only my
opinion.
2) It adds pointer to zend_auto_global into zend_compiled_variable. This
makes troubles for opcode caches - zend_compiled_variable(s) may lay in
shared memory, so they cannot point to process specific data. I think this
issue can be fixed using indirect pointer (index).
I would prefer rollback "auto-globals CV" patch and commit (or not) the
whole patch after conclusion.
Why did you reject auto-globals as overloaded arrays?
Thanks. Dmitry.
> -Original Message-
> From: Sara Golemon [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, January 24, 2007 10:58 PM
> To: internals@lists.php.net; Dmitry Stogov; Andi Gutmans;
> Andrei Zmievski
> Subject: [PHP-DEV] Runtime-JIT, the whole enchilada
>
>
> Dmitry-
>
>You asked for it, you get it :) Hopefully it'll be
> self-explanatory,
> the one part I hope you don't notice is that I put the
> auto_global check
> back into fetch_simple_variable_ex in order to force direct access to
> autoglobals ($foo = $_GET;foreach($_POST as ...) etc...) as
> non-auto-globals. Ultimately this made catching the
> difference between
> a whole var access and a dim/obj access much more
> straight-forward and
> computationally cheap. It comes at a slight cost for those
> fetches, but
> hopefully they're in the minority.
>
> Bench numbers with this patch:
> simple 0.461
> simplecall 1.985
> simpleucall2.900
> simpleudcall 3.488
> mandel 2.136
> mandel23.192
> ackermann(7) 3.490
> ary(5) 0.154
> ary2(5)0.137
> ary3(2000) 1.076
> fibo(30) 9.766
> hash1(5) 0.423
> hash2(500) 0.307
> heapsort(2)0.799
> matrix(20) 0.526
> nestedloop(12) 0.866
> sieve(30) 0.630
> strcat(20) 0.303
>
> Total 32.639
>
> -Sara
>
>
Index: main/php_variables.c
===
RCS file: /repository/php-src/main/php_variables.c,v
retrieving revision 1.136
diff -u -p -d -r1.136 php_variables.c
--- main/php_variables.c1 Jan 2007 09:29:35 - 1.136
+++ main/php_variables.c26 Jan 2007 10:23:11 -
@@ -628,9 +628,9 @@ void _php_import_environment_variables(z
}
}
-zend_bool php_std_auto_global_callback(char *name, uint name_len TSRMLS_DC)
+zend_bool php_std_auto_global_callback(zend_auto_global *auto_global, int
stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC)
{
- zend_printf("%s\n", name);
+ zend_printf("%s\n", auto_global->name);
return 0; /* don't rearm */
}
@@ -802,9 +802,13 @@ static void php_autoglobal_merge(HashTab
}
/* }}} */
-static zend_bool php_auto_globals_create_server(char *name, uint name_len
TSRMLS_DC);
-static zend_bool php_auto_globals_create_env(char *name, uint name_len
TSRMLS_DC);
-static zend_bool php_auto_globals_create_request(char *name, uint name_len
TSRMLS_DC);
+static zend_auto_global *php_server_auto_global = NULL;
+static zend_auto_global *php_env_auto_global = NULL;
+static zend_auto_global *php_request_auto_global = NULL;
+
+static zend_bool php_auto_globals_create_server(zend_auto_global *auto_global,
int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
+static zend_bool php_auto_globals_create_env(zend_auto_global *auto_global,
int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
+static zend_bool php_auto_globals_create_request(zend_auto_global
*auto_global, int stage, zval *ag_val, int fetch_op, zval *member TSRMLS_DC);
/* {{{ php_hash_environment
*/
@@ -861,16 +865,14 @@ int php_hash_environment(TSRMLS_D)
case 'e':
case 'E':
if (!jit_initialization && !_gpc_flags[3]) {
- zend_auto_global_disable_jit("_ENV",
sizeof("_ENV")-1 TSRMLS_CC);
- php_auto_globals_create_env("_ENV",
sizeof("_ENV")-1 TSRMLS_CC);
+ php_env_auto_global->armed =
php_auto_globals_create_env(php_env_auto_global, ZEND_RT, NULL, ZEND_FETCH_R,
NULL TSRMLS_CC);
_gpc_flags[3] = 1;
}
break;
case 's':
case 'S':
if (!jit_initialization && !_gpc_flags[4]) {
- zend_auto_global_disable_jit("_SERVER",
sizeof("_SERVER")-1 TSRMLS_CC);
- php_register_server_variables(TSRM
Re: [PHP-DEV] PHP 5.2.1RC4 Released
Windows build: http://downloads.php.net/edink/php-5.2.1RC4-Win32.zip (a4b7ac5a4a6a8cfc1580dd2e667b14ca) http://downloads.php.net/edink/php-5.2.1RC4-win32-installer.msi (28463a1c08e994e6510a7997c1297a99) http://downloads.php.net/edink/pecl-5.2.1RC4-Win32.zip (9b5df92540017478427f099c450d45a9) http://downloads.php.net/edink/php-debug-pack-5.2.1RC4-Win32.zip (8243540de80da275b69636574ac6983e) NTS (No thread safety build). Should only be used with CGI/FastCGI and CLI. http://downloads.php.net/edink/php-5.2.1RC4-nts-Win32.zip (999044354145d95c0d4e85dce2eb0f38) http://downloads.php.net/edink/pecl-5.2.1RC4-nts-Win32.zip (ab193ca706a4d06c793a149817863996) http://downloads.php.net/edink/php-debug-pack-5.2.1RC4-nts-Win32.zip (71cbe0d07b1334efda4cf5513773cd22) Edin Ilia Alshanetsky wrote: The final release candidate for PHP 5.2.1, RC4 is now available for download. Pending any problems this will be released as 5.2.1 next week, so this is the last chance to identify any critical issues before it is too late. If you have not tried any previous RCs, please do so now. The tar balls can be found at the URLs below and win32 binaries will follow shortly. http://downloads.php.net/ilia/php-5.2.1RC4.tar.bz2 (md5sum: f50578276f653b1f523150e3ff987f03) http://downloads.php.net/ilia/php-5.2.1RC4.tar.gz (md5sum: 361197eb2b21b36e2e20cb132da2cf16) I'd like to ask all developers to refrain from making any (no matter how trivial) commits to the 5.2 branch until 5.2.1 is released, if you feel you have a critical patch, please run it by me first, thanks. Ilia Alshanetsky 5.2 Release Master --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP6 - x64 SegFault
On 01/26/2007 10:27 AM, Chris Malton wrote: Hi, I'm new to the newsgroup and I'm trying to debug PHP 6 on a test server (x64 architecture). Why do you do that? I mean, PHP6 is not even an alpha and it's too early to test it unless you're a developer. However, for some unknown reason, it segfaults if I try to run it with any files that work in PHP 5.2.0. The segfault is at the end of most scripts, at the beginning of others. I test it from time to time on both Linux 64bit machines I have and I have to say I can't reproduce any crashes. What kind of OS is that (Solaris?)? What compiler did you use (GCC 4.1?)? -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
