It seems there is a problem in either the PHP's shutdown sequence in
php_request_shutdown() or destrutor order in ZE2. The problem is quite
simple, the module loaded via dl() (when libdl is used) is unloaded before
the objects it creates are destroyed. Consequently when Zend Engine tries to
de
> At 23:24 08/01/2004, Sterling Hughes wrote:
> >> >p.s. Is there a technical reason the function table could be shareable
> >> >across children? I can't think of one of the top of my head.
> >>
> >> I guess you're missing a 'not' in this question? :) Anyway, the reason
> >it
> >> cannot be shar
Hi Wez,
Thanks for you help so far. I decided to re-download php-src and start
over from scratch, I suspect the problem was that I didn't re-run
buildconf.bat.
I have one other issue that I'm sure can be fixed easily, I need to know
how I should grab SPL so that simplexml can compile. The bu
> >p.s. Is there a technical reason the function table could be shareable
> >across children? I can't think of one of the top of my head.
>
> I guess you're missing a 'not' in this question? :) Anyway, the reason it
> cannot be shared is that it also contains user-defined functions. It
> sta
hey,
i'm using php5-cvs, and building with apache2handler. when php is built
with TSRM, you can't set values like asp_tags or short_tags in your
php.ini file, because they are overridden by
zend_set_default_compile_time_values() (called from
compiler_globals_ctor()).
-sterling
--
PHP Internals
> At 20:57 08/01/2004, George Schlossnagle wrote:
>
> >On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
> >>
> >>Personally, I'm not convinced this is that case, even if the people we're
> >>dealing with run thousands of Apache processes per server (which they do).
> >
> >Unless they're running th
Is there some reason you don't want to look at the source?
On Thu, 8 Jan 2004, david wrote:
> does anyone know where i can find documentation for PHP's internal API?
> functions/macros like:
>
> zend_hash_next_index_insert
> zend_register_functions
> zend_make_printable_zval
> ...etc
>
> i am wri
does anyone know where i can find documentation for PHP's internal API?
functions/macros like:
zend_hash_next_index_insert
zend_register_functions
zend_make_printable_zval
...etc
i am writing a PHP extension and i have a few questions on a few APIs where
i need to understand what they really do
On Thu, 8 Jan 2004, Christian Schneider wrote:
> Rasmus Lerdorf wrote:
> > Yup, thousands of little servers with less than 100 httpd children on each
> > is how the biggest web load in the world is handled.
>
> I completely agree and think this is the way to do it. The only point to
> consider
On Jan 8, 2004, at 5:31 PM, Christian Schneider wrote:
Rasmus Lerdorf wrote:
Yup, thousands of little servers with less than 100 httpd children on
each is how the biggest web load in the world is handled.
I completely agree and think this is the way to do it. The only point
to consider might be
Rasmus Lerdorf wrote:
Yup, thousands of little servers with less than 100 httpd children on each
is how the biggest web load in the world is handled.
I completely agree and think this is the way to do it. The only point to
consider might be KeepAlive which binds processes without using any
CPU/I
On Thu, 8 Jan 2004, George Schlossnagle wrote:
> As a complete aside - I've always found it to be really hard to avoid
> context-switching myself to death running near that many processes. I
> believe the Y! folks had similar experience. I'm having trouble
> envisioning an app were that runs w
Hello Zeev,
Thursday, January 8, 2004, 10:40:19 PM, you wrote:
> At 23:34 08/01/2004, Ilia Alshanetsky wrote:
>>On January 08, 2004 04:11 pm, Zeev Suraski wrote:
>> > Well, if we really get to save 100K as Ilia imagined, for a thousand
>> > children, it's 100MB, and there are those with more. I
win32 build should handle this correctly now.
--Wez.
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "Blake Schwendiman" <[EMAIL PROTECTED]>
Cc: "'Marcus Boerger'" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, January 08, 2004 9:12 PM
Subject: Re: [PHP-DEV]
On Jan 8, 2004, at 4:40 PM, Zeev Suraski wrote:
At 23:34 08/01/2004, Ilia Alshanetsky wrote:
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we
can easily
> get
At 23:34 08/01/2004, Ilia Alshanetsky wrote:
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we can easily
> get 100K though.
'Freeing' 100k is not as difficult a
At 23:24 08/01/2004, Sterling Hughes wrote:
> >p.s. Is there a technical reason the function table could be shareable
> >across children? I can't think of one of the top of my head.
>
> I guess you're missing a 'not' in this question? :) Anyway, the reason it
> cannot be shared is that it also co
On Jan 8, 2004, at 4:24 PM, Sterling Hughes wrote:
p.s. Is there a technical reason the function table could be
shareable
across children? I can't think of one of the top of my head.
I guess you're missing a 'not' in this question? :) Anyway, the
reason it
cannot be shared is that it also cont
On January 08, 2004 04:11 pm, Zeev Suraski wrote:
> Well, if we really get to save 100K as Ilia imagined, for a thousand
> children, it's 100MB, and there are those with more. I doubt we can easily
> get 100K though.
'Freeing' 100k is not as difficult as it sounds in PHP 5 when you consider
that
At 21:59 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 2:12 PM, Zeev Suraski wrote:
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of
Hello Blake,
for the moment i removed the order dependancy by making it slower.
Thursday, January 8, 2004, 9:57:38 PM, you wrote:
> Does your fix mean that there is no order dependence now?
> Thanks,
> Blake
> -Original Message-
> From: Marcus Boerger [mailto:[EMAIL PROTECTED]
> Sent:
Does your fix mean that there is no order dependence now?
Thanks,
Blake
-Original Message-
From: Marcus Boerger [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 08, 2004 1:30 PM
To: Blake Schwendiman
Cc: [EMAIL PROTECTED]
Subject: [PHP-DEV] Re: SPL not Working (was: SimpleXML and Defaul
> >I don't really understand why that can evolve like that. With PHP4,
results
> >are always the same (and that seems normal :p).
>
> Your apache is configured to kill childs after certain amount
> of requests so of course it makes this look like 'random'.
> There's nothing wrong here.
On Thu, Jan 08, 2004 at 08:23:00PM -, Wez Furlong wrote:
> And you have c:/program files/php dir in your path, right?
> If you don't have it in your path, it won't work.
And a PHPRC environment variable set to that as well.
Don't know why this wasn't the default recommendation on installing P
Hmm, interesting.
The order comes from the order that the extension dirs are sorted
in by the glob() function (so, yes it's alphabetical).
I have some dependency based ordering code for shared extensions
under the win32 build, so I could adapt that for the internals_functions.c
stuff, but we woul
Hello Blake,
fixed.
Thursday, January 8, 2004, 9:14:07 PM, you wrote:
> Hello Marcus,
> Okay. I tracked it down. I am using the new build system so that spl
> gets compiled in. However, the problem is that simplexml is getting
> initialized before spl and simplexml needs the interface for sp
And you have c:/program files/php dir in your path, right?
If you don't have it in your path, it won't work.
> On Thu, Jan 08, 2004 at 07:09:01PM -, Wez Furlong wrote:
> > That doesn't work, since the php5*.dll is not found in the
> > same dir as the exe.
>
> Huh? What I've been doing...
>
Hello Marcus,
Okay. I tracked it down. I am using the new build system so that spl
gets compiled in. However, the problem is that simplexml is getting
initialized before spl and simplexml needs the interface for spl to be
initialized first.
I found that the order of module initialization is st
On Thu, Jan 08, 2004 at 07:09:01PM -, Wez Furlong wrote:
> That doesn't work, since the php5*.dll is not found in the
> same dir as the exe.
Huh? What I've been doing...
To run CLI the script's pound bang is
#! c:/progra~1/php/cli/php
To run CGI the script's pound bang is
#! c:/progra~
Uh..we had this discussion back when CLI was introduced..
please don't start another useless thread about this.
It's fine as it is, move along.
--Jani
On Thu, 8 Jan 2004, Daniel Convissor wrote:
>On Thu, Jan 08, 2004 at 06:56:00PM -, Wez Furlong wrote:
>> If yo
On Thu, 8 Jan 2004, Armel FAUVEAU wrote:
>Hi Jani,
>
>Thank's for your response.
>
>> I tried your script and couldn't reproduce such big numbers.
>> Plus the memory usage leveled to 54152 bytes after some requests
>> to each apache child. This was with using the latest CVS checkout
On Thu, Jan 08, 2004 at 06:56:00PM -, Wez Furlong wrote:
> If you need to configure php5 separately from php4, you're going to be
> editing your server config anyway, so (IMO at least) this is not an issue.
But why add needless steps? Let alone, I suspect the majority of users
don't play aro
On Jan 8, 2004, at 2:12 PM, Zeev Suraski wrote:
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of Apache processes per server
(which they do).
Un
Hi Jani,
Thank's for your response.
> I tried your script and couldn't reproduce such big numbers.
> Plus the memory usage leveled to 54152 bytes after some requests
> to each apache child. This was with using the latest CVS checkout
> of PHP 5.
Ok, i have make a test with th
Hi Again:
php.ini-dist and php.ini-recommended are generally formatted with CR LF
line endings for DOS format. But the new snapshot has some endings that
are just LF. It would be nice if someone could fix it.
I just updated my cvs working directory and the files are fine there and
have't been
Hi Dan,
there is something borked. mysql_drop_db() is deprecated and on the
doc page there is a note :
[snip]
Warning
This function will not be available if the MySQL extension was built against a MySQL 4.x
client library.
[/snip]
There is something borked with the libs that you use?
Andrey
Dani
Or the header files are wrong..that func is available
with MYSQL_VERSION_ID < 4. Something wrong with the build
system perhaps? :)
--Jani
On Thu, 8 Jan 2004, Wez Furlong wrote:
>Edin,
>
>looks like the libmysql.dll in the php-win32-dev/template/dlls
>folder is out of dat
Edin,
looks like the libmysql.dll in the php-win32-dev/template/dlls
folder is out of date (it doesn't have mysql_drop_db here either).
--Wez.
>The procedure entry point mysql_drop_db could not be located in the
>dynamic link library LIBMYSQL.dll
--
PHP Internals - PHP Runtime Developm
On Thu, 8 Jan 2004, Zeev Suraski wrote:
> Obviously we're talking about httpd children and not 1,000
> roots... Anyway, depending on the module, if there's any sort of RINIT
> initialization, the CoW trick doesn't work very well and it consumes some
> per-process memory. There's also the funct
Hi Wez:
On Thu, Jan 08, 2004 at 07:00:18PM -, Wez Furlong wrote:
> Seeing any error messages that you get would help to diagnose the
> problem :)
Pardon me. Given the context, I thought it would be apparent that it was
the windows message box:
PHP Warning: PHP Startup: Unable to load dyn
At 20:57 08/01/2004, George Schlossnagle wrote:
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people we're
dealing with run thousands of Apache processes per server (which they do).
Unless they're running thousands of apache server in
That doesn't work, since the php5*.dll is not found in the
same dir as the exe.
> On Thu, Jan 08, 2004 at 06:56:00PM -, Wez Furlong wrote:
>
> > The old style dir structure meant that you had to rename the CGI and
> > then move the CLI out of a sub-directory in order to be able to use
> > bot
While I dont care if the name changes for php5, I dont buy the premise
that more and more people will be using php outside the web. I think
cli has it's uses, but I think it will be a marginal group of people who
make large use of it.
Shane
Wez Furlong wrote:
If you need to configure php5 sep
Don't you nowadays need to have external mysql dlls with PHP 5?
--Jani
On Thu, 8 Jan 2004, Wez Furlong wrote:
>Seeing any error messages that you get would help to diagnose the
>problem :)
>
>--Wez.
>
>> Running php5-win32-200401081130. Uncommented several extensions in
>> php
On Thu, Jan 08, 2004 at 06:56:00PM -, Wez Furlong wrote:
> The old style dir structure meant that you had to rename the CGI and
> then move the CLI out of a sub-directory in order to be able to use
> both CLI and CGI on the same box;
Or don't change anything and just call the CLI using a the
Seeing any error messages that you get would help to diagnose the
problem :)
--Wez.
> Running php5-win32-200401081130. Uncommented several extensions in
> php.ini. Adjusted my extension_dir. All of the extensions loaded just
> fine, except php_mysql.dll. The file is in the appropriate place a
On Thu, 8 Jan 2004, Zeev Suraski wrote:
> Personally, I'm not convinced this is that case, even if the people we're
> dealing with run thousands of Apache processes per server (which they do).
But could you explain where you see the significant incremental memory
usage going from 20 to 2000 httpd
On Jan 8, 2004, at 1:39 PM, Zeev Suraski wrote:
Personally, I'm not convinced this is that case, even if the people
we're dealing with run thousands of Apache processes per server (which
they do).
Unless they're running thousands of apache server instances (not just
children), shouldn't the memo
If you need to configure php5 separately from php4, you're going to be
editing your server config anyway, so (IMO at least) this is not an issue.
The CLI version should remain php.exe (this has been discussed before).
Consider the CGI name change a progressive one that will help avoid
confusion w
I tried your script and couldn't reproduce such big numbers.
Plus the memory usage leveled to 54152 bytes after some requests
to each apache child. This was with using the latest CVS checkout
of PHP 5.
--Jani
On Thu, 8 Jan 2004, Armel FAUVEAU wrote:
>Hi all,
Hi:
Running php5-win32-200401081130. Uncommented several extensions in
php.ini. Adjusted my extension_dir. All of the extensions loaded just
fine, except php_mysql.dll. The file is in the appropriate place and has
the appropriate permissions. Even tried giving everyone full control over
t
At 19:53 08/01/2004, Rasmus Lerdorf wrote:
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> It wouldn't hurt anyone and it *is* a pressing problem from talks I've had
> with all sorts of ppl that have high traffic machines.
You must be talking to different people than I am.
We are :)
100 or so function
Hi Folks:
Downloaded the latest snapshot, php5-win32-200401081130, and am enjoying
the new file layout.
Both the CGI and CLI exe's are now in the base directory. CLI is called
"php.exe" and the CGI is called "php-cgi.exe." Please consider reversing
the names. Making the CLI "php-cli.exe" an
On Thu, 8 Jan 2004, Andi Gutmans wrote:
> It wouldn't hurt anyone and it *is* a pressing problem from talks I've had
> with all sorts of ppl that have high traffic machines.
You must be talking to different people than I am. 100 or so functions
all sitting in shared pages and thus shared across
On Jan 8, 2004, at 12:22 PM, Marcus Boerger wrote:
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be
more
dangerous than the performance benefit. Which, BTW, I estmate as
pretty
mini
On Thu, 08 Jan 2004, Andi Gutmans wrote:
> You are all missing the point. All the ext/standard would still be enabled
> by default, but it would allow people with very high traffic sites who need
> to save every bit of memory they can to build a lean-and-mean version of
> PHP.
If they want lean
Hi all,
I wanted to compare the memory usage of PHP4 and PHP5 (Beta 3) on a same
script. And i observed a strange problem.
So, here is a small test (if you want to reproduce it).
First, i write a small and short php script.
It just make a simple memory_get_usage() (with a number_format for the
p
Hello Andi,
Thursday, January 8, 2004, 6:02:42 PM, you wrote:
> At 02:24 PM 1/8/2004 +0100, Christian Schneider wrote:
>>Stanislav Malyshev wrote:
>>>I'm concerned that this problem of breaking common platform might be more
>>>dangerous than the performance benefit. Which, BTW, I estmate as prett
Andi Gutmans wrote:
I don't even mind if --disable-all doesn't disable ext/standard but it'd
be nice that if we do a split to core/ and standard/ (I wouldn't go into
more granularity than that) that we could have a --disable-standard.
I see no problem if it's not included in --disable-all. It is
Hello Christian,
Thursday, January 8, 2004, 2:24:33 PM, you wrote:
> Stanislav Malyshev wrote:
>> I'm concerned that this problem of breaking common platform might be more
>> dangerous than the performance benefit. Which, BTW, I estmate as pretty
>> minimal - code space is shared on all modern O
Andi Gutmans wrote:
At 06:43 PM 1/8/2004 +0200, Jani Taskinen wrote:
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for leven
On January 08, 2004 12:02 pm, Andi Gutmans wrote:
> You are all missing the point. All the ext/standard would still be enabled
> by default, but it would allow people with very high traffic sites who need
> to save every bit of memory they can to build a lean-and-mean version of
> PHP. These kinds
At 06:43 PM 1/8/2004 +0200, Jani Taskinen wrote:
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
>meta
At 02:24 PM 1/8/2004 +0100, Christian Schneider wrote:
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
On Thu, 8 Jan 2004, Wez Furlong wrote:
>As Stas mentioned, I'm not sure that this is a good idea, unless
>we split some of these things out of ext/standard and into their
>own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
>metaphone etc.), ext/std_hash (crc32, sha1) and have
Removing few functions from standard will not save more then a few kilobytes
from the final binary (stripped). However, it'll create problems for people
who try to write portable scripts relying on those extensions. For example
ext/ctype is pretty basic functionality and is even enabled by defau
Hi!
I compile php 4.3.4 under Fedora Core 1 with this code: ./configure --disable-cgi and
PHP-GTK but when I try to load the php-gtk extension with dl() PHP return me this
warning, what can I do to support dynamic librarys?¿
Warning: dl(): Unable to load dynamic library
'/usr/local/lib/php/ex
I need my cv for some websites
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
I'm concerned that this problem of breaking common platform might be more
dangerous than the performance benefit. Which, BTW, I estmate as pretty
minimal - code space is shared on all modern OSes anyway, so a little
I think that's a good point for leaving it the way it
On Thu, 8 Jan 2004, Wez Furlong wrote:
> As Stas mentioned, I'm not sure that this is a good idea, unless
> we split some of these things out of ext/standard and into their
> own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
> metaphone etc.), ext/std_hash (crc32, sha1) and h
As Stas mentioned, I'm not sure that this is a good idea, unless
we split some of these things out of ext/standard and into their
own extensions; ext/std_regex, ext/std_string (for levenstein, soundex,
metaphone etc.), ext/std_hash (crc32, sha1) and have those extensions
compiled in by default.
II
AG>> but I think it'd be nice to brainstorm about this to see how we can
AG>> solve this, maybe for 5.1? If regex isn't required by the core that's
AG>> one of the first things I'd like to see disabled when building with
AG>> --disable-all. I think ext/standard should maybe be split up into
AG>> tw
Hey,
I just compiled PHP using --disable-all and realized that there's a shit
load of relatively useless stuff still being compiled into it.
The first thing I realized is that regex is still being compiled in by
default. Are any parts of PHP's core relying on regex, thus, requiring it
to be in
At 06:59 PM 1/7/2004 -0500, Adam Maccabee Trachtenberg wrote:
> So i'd say let us add a method for returning the complete content. Adam
> could you do that?
That wouldn't be too difficult (although I am busy for the next day or
two). However, as much as I loathe toggles, I'm wondering if it
wouldn'
74 matches
Mail list logo
