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
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
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 (mainly in
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 don't
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 Runtime
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() /
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
handler
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 improved
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.
Should
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 wouldn't
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 got.
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 local
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 extension
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 look at
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,
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 oversights
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
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 order
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.
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_SIGNALS
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
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
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
it is not problematic to include
Update APD documentation.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
26 matches
Mail list logo
