> Note that what you are saving by combining the files into one is just a
> single stat syscall per file. And that can be alleviated by setting
> apc.stat=0 in your config. That of course means you need to restart
> your server or flush your cache whenever you want to update the files.
> In apc.s
Update APD documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I found out the hard way that phpize won't build some extensions like
ext/openssl because they have no config.m4, only a config0.m4. I could not
find a reason why this shouldn't work and propose the patch below for phpize
to support config0.m4 as well as config9.m4.
This will generate a standalone
> On 21.01.2008 14:06, Lucas Nealan wrote:
>> I found out the hard way that phpize won't build some extensions like
>> ext/openssl because they have no config.m4, only a config0.m4. I could not
>> find a reason why this shouldn't work and propose the patch below for
On 1/21/08 2:33 PM, "Antony Dovgal" <[EMAIL PROTECTED]> wrote:
> On 22.01.2008 01:07, Lucas Nealan wrote:
>> There is only one extension with config9.m4, the recode extension and it
>> appears to be using this expressly outside of the context of phpize however
>
Hi Internals,
I am proposing the following RFC to improve signal handling in the Zend
Engine:
http://wiki.php.net/rfc/zendsignals
The purpose of zend internal deferred signal handling is to improve the
stability of PHP and extensions when running under any forking SAPI.
Additionally heavy users
Hi Dmitry,
> I like the idea, and I think we don't need --enable-signals options.
I would like to have this enabled by default and this would be very easy to
change. We¹ve been running in production for a few months and we use the
option to make it easier to disable at build time for testing. Ide
Hi Stas,
> Looks good. If ti works, I don't think we need two signal models - new
> one would be OK. I'm not sure what happens with win32 though.
This has not been tested on windows but it `should` be unaffacted. If built
with ZEND_MAINTAINER_ZTS or if sigaction() is not detected then ZEND_SIGNAL
Hi Johannes,
> thanks for the patch, next to platform specific stuff I'm wondering
> whether the shutdown order is right:
> [..snip..]
> Destructors can be PHP code, as can some ob callback so I think the order
> should be changed.
Yes, great catch, the order is incorrect. We use a different orde
I was waiting after Rasmus said he wanted to compare to the internal
Signals code they have at Yahoo before asking againd about inclusion.
Gopal is familiar with the Yahoo code as well and we're planning to
get together tomorrow and to review and make sure there aren't any
critial oversight
I've done a bunch of stuff with svn commit hooks and am willing to
lend a hand.
-lucas (mobile)
On Jul 24, 2008, at 17:06, "Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote:
Now that Subversion 1.5 has been out for a little while and it is at
the point where it might actually have some benefit to
> I was waiting after Rasmus said he wanted to compare to the internal
> Signals code they have at Yahoo before asking againd about inclusion.
> Gopal is familiar with the Yahoo code as well and we're planning to
> get together tomorrow and to review and make sure there aren't any
> critial oversig
I've updated the patch for Zend Signal Handling, the latest version is
available on the wiki rfc page:
http://wiki.php.net/rfc/zendsignals
The update solves the reentrance issue with using the a zend linked list in
the default signal handler. I've also added a debug only check, at least for
now,
> On 7/30/08 6:11 AM, "Lukas Kahwe Smith" <[EMAIL PROTECTED]> wrote:
> Not so happy that it was not possible to get this committed over the
> weekend. Johannes did a quick review and it seems like it has enough
> support from people and is low risk enough to get committed now. Lets
> hope no extens
On 7/30/08 11:54 AM, "Stanisla Malyshev" <[EMAIL PROTECTED]> wrote:
> I have a couple of questions about the patch:
> 1. Why allocate fixed-size buffer via individual malloc's on each
> activate and free it on each deactivate? Won't it be better to just
> allocate it once and use it?
I'll take a l
Hi!
On 7/31/08 11:07 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> I worked a bit on the ZTS version, this actually fixes many problems with ZTS
> on non-windows plateforms :)
[...snip...]
> I will send a modified version of your patch tomorrow.
Sounds great, can't wait to see what you've g
On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> Hi,
> The ZTS-enabled version of your patch can be found at [1] :)
Thanks Arnaud. I've gone ahead and made the HEAD patch already, wasn't as
bad as I thought it might be. I'll review this hopefully by tomorrow and
then pull into my
Reviewed to my ability and will soon be posting the updated patch for 5_3
and 6 as well as wiki changes.
On 8/1/08 6:45 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> The ZTS-enabled version of your patch can be found at [1] :)
> Changes:
> Zend Signal Handling is now enabled in ZTS builds.
S
On 8/3/08 3:00 AM, "Pierre Joye" <[EMAIL PROTECTED]> wrote:
> We also provide binaries for non ZTS mode, so if the patch is not
> ready for Windows, it should disable this feature on Windows.
I was presuming that non-zts, non-cygwin windows will not satisfy the
sigaction requirement, thus we woul
Greetings!
On 8/3/08 9:37 PM, "Arnaud LB" <[EMAIL PROTECTED]> wrote:
> If sigaction is not available Zend Signal Handling will not be
> enabled, so it will not be enabled on Windows (I assume sigaction is
> not available on Windows, it is ?).
> For pthreads and sigprocmask, tsrm_sigmask() can be i
On 8/4/08 11:51 PM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> global_sigmask is initialized using sigfillset(), so it contains _all_ signals
> (except SIGSEGV, etc because non-blockable or not safe to block) and there is
> no need to add signals to global_sigmask it in zend_signal() /
> zen
On 8/5/08 3:45 AM, "Arnaud Le Blanc" <[EMAIL PROTECTED]> wrote:
> In the case of pcntl_signal(), if it registers a handler for a signal, the
> signal will be delivered to zend_signal_handler_defer(), which will call
> zend_signal_handler() if not in critical section, which will call the actual
> h
On 8/11/08 8:52 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I'll try to review it on Tuesday/Wednesday.
> Thanks. Dmitry.
I've just updated the patches. Only some very minor changes as discussed
before and they should cleanly apply against current cvs.
-lucas
--
PHP Internals - PHP Runti
On 8/13/08 1:09 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I took a look into patch and I still don't like it.
> I may miss some things and make mistakes so correct me if I'm wrong.
> 1) It makes some slowdown for all SAPIs except Apache1, because it adds
> additional block/unblock code (mai
On 8/13/08 2:10 AM, "Dmitry Stogov" <[EMAIL PROTECTED]> wrote:
> I wasn't serious about removing them.
>
> Anyway zend_alloc.c and zend_hash.c don't work with shared memory.
> It's possible to reuse zend_alloc.c to allocate blocks from SHM, but
> it's not its primary purpose. If APC don't do it I
Hello,
Apache 1.x SAPI will occasionally timeout with a "Read POST information
timeout" error instead of a "send timeout" error as it should. This will
happen if the alarm timeout occurs in a POST request, at any point after the
post is read (ie. php_execute_script). This is because the
hard_timeo
How shall we continue with this patch?
Arnaud, I need an updated HEAD patch to match the changes made in 5.3.
There's valid concern about performance in ZTS, which seems hard to address
without the __thread changes. It seems you are working on to get this into
6.0.
Dmitry, Lukas, Arnaud and othe
27 matches
Mail list logo
